Re: Admission Control
От | Mark Kirkwood |
---|---|
Тема | Re: Admission Control |
Дата | |
Msg-id | 4C3687C4.7040301@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Admission Control (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: Admission Control
Re: Admission Control |
Список | 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.
В списке pgsql-hackers по дате отправления: