Re: more anti-postgresql FUD

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.

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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