On Tue, 2013-07-02 at 14:02 +0200, Andres Freund wrote:
> Ok, so you want some benchmark results. I spent 20 minutes concocting some
> quick tests. Here you go:
>
> master (384f933046dc9e9a2b416f5f7b3be30b93587c63):
> tps = 155075.448341 (including connections establishing)
> tps = 155259.752267 (excluding connections establishing)
>
> dev (384f933046dc9e9a2b416f5f7b3be30b93587c63 + patch):
> tps = 151450.387021 (including connections establishing)
> tps = 152512.741161 (excluding connections establishing)
>
> That's about a 3% regression.
I had a little trouble reproducing this result on my workstation, and my
previous tests on the 64-core box didn't seem to show a difference
(although I didn't spend a lot of time on it, so perhaps I could try
again).
I did see some kind of difference, I think. But the fastest run without
the patch beat the slowest run with the patch by about 1.4%. The delta
generally seemed closer to 0.5%. The noise seemed to be around 2.6%.
Why did you do this as a concurrent test? The difference between reading
hints and PD_ALL_VISIBLE doesn't seem to have much to do with
concurrency.
Regardless, this is at least a concrete issue that I can focus on, and I
appreciate that. Are scans of small tables the primary objection to this
patch, or are there others? If I solve it, will this patch make real
progress?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
