From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep and shutdown Re: Sync Rep v19 |
Date: | 2011-03-21 17:04:46 |
Message-ID: | AANLkTi=ZM=uBE70qLsuPL6W7pe47GvQ+VLui7WgdDneH@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 21, 2011 at 12:29 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> pgbench -i -s 50 test
> Two runs of "pgbench -c 10 -M prepared -T 600 test" with 1 sync standby -
> server configs etc were mailed upthread.
>
>> - performance as of commit e148443ddd95cd29edf4cc1de6188eb9cee029c5
>
> 1158 and 1306 (avg 1232)
>>
>> - performance as of current git master
>
> 1181 and 1280 (avg 1230,5)
>>
>> - performance as of current git master with
>> sync-standbys-defined-rearrangement applied
>
> 1152 and 1269 (avg 1210,5)
Hmm, that doesn't appear to show the 20% regression Simon claimed
upthread. That's good... but I'm confused as to how you are getting
numbers this high at all without a BBU. If every commit has to wait
for two consecutive fsyncs, cranking out 1200+ commits per second is a
lot. Maybe it's just barely plausible if these are 15K drives and all
the commits are piggybacking on the fsyncs at top speed, but, man,
that's fast.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-03-21 17:05:25 | Re: Rectifying wrong Date outputs |
Previous Message | Josh Berkus | 2011-03-21 16:47:21 | Re: 2nd Level Buffer Cache |