5 ms·
That example benchmark he has is weird. You'd probably want to test this one something with at least a million rows, taking more than a 100ms and probably actu
by meshko 11y ago
That example benchmark he has is weird. You'd probably want to test this one something with at least a million rows, taking more than a 100ms and probably actually returning some data. This sub-second difference can be attributed to solar flairs. Also it is not clear that it is not just result of the table getting cached.
Did they implement a feature like this and not run a real performance test?
- quizotic 11y agoRobert Haas is the real deal, and will certainly have tested this feature. Perhaps I missed it, but I don't think the post specified how many rows were in the source. Could have been more than a million. Having a relatively expensive filter (regex) eliminating all results keeps the performance picture clearer. Anything done with a tuple that passes the filter would apply to both the regular and the parallel scan cases, so eliminating the results highlights just the difference between regular and parallel scans
- meshko 11y agoI really really doubt that it can process a million uncached rows under a second. But yeah, I just tested an million was not a good example because it does take only a bit over a second on decent hardware. So perhaps should have said 10 million. I agree about not returning any results being the right test.
- rachbelaid 11y agoIt has been tested and discuted during a long time. Check the thread if you want to know more about this. http://www.postgresql.org/message-id/flat/CAA4eK1KTv73uD9_W5wR4HiMZ_hgi8oseWncxbC53XwZDp-8aEg@mail.gmail.com#CAA4eK1KTv73uD9_W5wR4HiMZ_hgi8oseWncxbC53XwZDp-8aEg@mail.gmail.com http://www.postgresql.org/message-id/flat/CAA4eK1KTv73uD9_W5... Keep in mind that's the first pieces and not all the patches has merged yet concerning this feature. Still some on progress.