From: | Alexander Staubo <alex(at)purefiction(dot)net> |
---|---|
To: | andrew(at)supernews(dot)com |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: more anti-postgresql FUD |
Date: | 2006-10-13 15:43:33 |
Message-ID: | D95B1AB5-C6AA-4943-AEA5-7593B6019558@purefiction.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Oct 13, 2006, at 17:35 , Andrew - Supernews wrote:
> On 2006-10-13, Alexander Staubo <alex(at)purefiction(dot)net> wrote:
>> On Oct 13, 2006, at 17:13 , Andrew - Supernews wrote:
>>> Your disk probably has write caching enabled. A 10krpm disk
>>> should be
>>> limiting you to under 170 transactions/sec with a single connection
>>> and fsync enabled.
>>
>> What formula did you use to get to that number?
>
> It's just the number of disk revolutions per second. Without
> caching, each
> WAL flush tends to require a whole revolution unless the on-disk
> layout of
> the filesystem is _very_ strange. You can get multiple commits per WAL
> flush if you have many concurrent connections, but with a single
> connection
> that doesn't apply.
Makes sense. However, in this case I was batching updates in
transactions and committing each txn at 1 second intervals, all on a
single connection. In other words, the bottleneck illustrated by this
test should not be related to fsyncs, and this does not seem to
explain the huge discrepancy between update (1,000/sec) and insert
(9,000 inserts/sec, also in 1-sec txns) performance.
Alexander.
From | Date | Subject | |
---|---|---|---|
Next Message | John D. Burger | 2006-10-13 15:47:05 | Re: A query planner that learns |
Previous Message | Tomi NA | 2006-10-13 15:36:15 | Re: UTF-8 |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew - Supernews | 2006-10-13 15:48:50 | Re: more anti-postgresql FUD |
Previous Message | Andrew - Supernews | 2006-10-13 15:35:37 | Re: more anti-postgresql FUD |