Hacker News Reader

Comment by meshko | Hacker News Reader

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?

View on HN

Robert 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

I 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.

It can definitely process a million uncached rows in well under a second :P Have you used Postgres recently?

You can even insert well above a million rows/second...

It 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_W5...

Keep in mind that's the first pieces and not all the patches has merged yet concerning this feature. Still some on progress.

Reply on news.ycombinator.com