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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-01-23 15:15:31 | Re: patch: ALTER TABLE IF EXISTS |
Previous Message | Dimitri Fontaine | 2012-01-23 15:04:20 | Re: Inline Extension |