Skip site navigation (1) Skip section navigation (2)

Re: basic pgbench runs with various performance-related patches

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: basic pgbench runs with various performance-related patches
Date: 2012-01-23 15:09:06
Message-ID: CA+TgmoZ9_UPAO33_+8eM-JF33KK_LNw4gmA4bi-2hgvp-a+Ydw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jan 23, 2012 at 9:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-23 15:15:31
Subject: Re: patch: ALTER TABLE IF EXISTS
Previous:From: Dimitri FontaineDate: 2012-01-23 15:04:20
Subject: Re: Inline Extension

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group