Re: Admission Control

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.

In response to

Responses

Browse pgsql-hackers by date

  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