Re: Eliminating PD_ALL_VISIBLE, take 2 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Eliminating PD_ALL_VISIBLE, take 2
Date
Msg-id 1372785151.19747.114.camel@jdavis
Whole thread Raw
In response to Re: Eliminating PD_ALL_VISIBLE, take 2  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Eliminating PD_ALL_VISIBLE, take 2
Re: Eliminating PD_ALL_VISIBLE, take 2
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: XLogInsert scaling, revisited
Next
From: Andres Freund
Date:
Subject: Re: XLogInsert scaling, revisited