From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Admission Control |
Date: | 2010-07-09 02:21:56 |
Message-ID: | 4C3687C4.7040301@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/07/10 12:58, Mark Kirkwood wrote:
> On 09/07/10 05:10, Josh Berkus wrote:
>> Simon, Mark,
>>
>>> Actually only 1 lock check per query, but certainly extra processing
>>> and
>>> data structures to maintain the pool information... so, yes certainly
>>> much more suitable for DW (AFAIK we never attempted to measure the
>>> additional overhead for non DW workload).
>>
>> I recall testing it when the patch was submitted for 8.2., and the
>> overhead was substantial in the worst case ... like 30% for an
>> in-memory one-liner workload.
>>
>
> Interesting - quite high! However I recall you tested the initial
> committed version, later additions dramatically reduced the overhead
> (what is in the Bizgres repo *now* is the latest).
Purely out of interest, since the old repo is still there, I had a quick
look at measuring the overhead, using 8.4's pgbench to run two custom
scripts: one consisting of a single 'SELECT 1', the other having 100
'SELECT 1' - the latter being probably the worst case scenario. Running
1,2,4,8 clients and 1000-10000 tramsactions gives an overhead in the
5-8% range [1] (i.e transactions/s decrease by this amount with the
scheduler turned on [2]). While a lot better than 30% (!) it is
certainly higher than we'd like.
Cheers
Mark
[1] I got the same range for pgbench select-only using its usual workload
[2] As compared to Bizgres(8.2.4) and also standard Postgres 8.2.12.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-07-09 02:26:23 | Re: Admission Control |
Previous Message | Mark Kirkwood | 2010-07-09 00:58:37 | Re: Admission Control |