That's about 0.52% slower with the patch. Because there was over 10%
variation in the numbers with the patch, I tried leaving out the four
highest outliers on both, in case it was the result of some other
activity on the system (even though this machine should have been
pretty quiet over the weekend) and the difference fell to 0.09%.
I don't know if this difference is enough to worry about; it might
depend on whether we're comparing to the unpatched version or the
previous patch. If it comes to choosing between a 1% to 2%
performance gain for a "normal" case versus elimination of O(N^2)
behavior for a worst-case scenario, I'm not sure which should win --
especially in the absence of benchmarks showing the pessimal case.
What would be the most productive focus for benchmarks at this point?
The artificial pessimal case?
My instinct says that the variation is probably just noise, of no great
significance. I'm personally not terribly worried about the O(n^2) case,
but I think the patch is probably useful anyway, as a basis for other
people to try to improve the item selection algorithm further.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
