Re: basic pgbench runs with various performance-related patches - Mailing list pgsql-hackers

From Robert Haas
Subject Re: basic pgbench runs with various performance-related patches
Date
Msg-id CA+TgmoZ9_UPAO33_+8eM-JF33KK_LNw4gmA4bi-2hgvp-a+Ydw@mail.gmail.com
Whole thread Raw
In response to Re: basic pgbench runs with various performance-related patches  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: basic pgbench runs with various performance-related patches  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Jan 23, 2012 at 9:31 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Test duration is important for tests that don't relate to pure
> contention reduction, which is every patch apart from XLogInsert.

Yes, I know.  I already said that I was working on more tests to
address other use cases.

> I'm very happy to see that your personal work has resulted in gains
> and these results are valid tests of that work, IMHO. If you only
> measure throughput you're only measuring half of what users care
> about. We've not yet seen any tests that confirm that other important
> issues have not been made worse.

I personally think throughput is awfully important, but clearly
latency matters as well, and that is why *even as we speak* I am
running more tests.  If there are other issues with which you are
concerned besides latency and throughput, please say what they are.

> On particular patches....
>
> * background-clean-slru-v2 related very directly to reducing the
> response time spikes you showed us in your last set of results. Why
> not repeat those same tests??

I'm working on it.  Actually, I'm attempting to improve my previous
test configuration by making some alterations per some of your
previous suggestions.  I plan to post the results of those tests once
I have run them.

> * removebufmgrfreelist-v1 related to the impact of dropping
> tables/index/databases, so given the variability of the results, that
> at least shows it has no effect in the general case.

I think it needs some tests with a larger scale factor before drawing
any general conclusions, since this test, as you mentioned above,
doesn't involve much buffer eviction.  As it turns out, I am working
on running such tests.

> That patch comes with the proviso, stated in comments:
> "We didn't get the lock, but read the value anyway on the assumption
> that reading this value is atomic."
> So we seem to have proved that reading it without the lock isn't safe.

I am not sure what's going on with that patch, but clearly something
isn't working right.  I don't know whether it's that or something
else, but it does look like there's a bug.

> The remaining patch you tested was withdrawn and not submitted to the CF.

Oh.  Which one was that?  I thought all of these were in play.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Inline Extension
Next
From: Robert Haas
Date:
Subject: Re: patch: ALTER TABLE IF EXISTS