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