Re: sustained update load of 1-2k/sec

From: Tom Lane
Subject: Re: sustained update load of 1-2k/sec
Date: ,
Msg-id: 18000.1124460545@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: sustained update load of 1-2k/sec  (Andreas Pflug)
List: pgsql-performance

Tree view

sustained update load of 1-2k/sec  (Mark Cotner, )
 Re: sustained update load of 1-2k/sec  (Bob Ippolito, )
  Re: sustained update load of 1-2k/sec  (Mark Cotner, )
   Re: sustained update load of 1-2k/sec  (Bob Ippolito, )
  Re: sustained update load of 1-2k/sec  (Tom Lane, )
   Re: sustained update load of 1-2k/sec  (Andreas Pflug, )
    Re: sustained update load of 1-2k/sec  (Tom Lane, )
    Re: sustained update load of 1-2k/sec  (Ron, )
   Re: sustained update load of 1-2k/sec  (PFC, )
    Re: sustained update load of 1-2k/sec  (Mark Cotner, )
 Re: sustained update load of 1-2k/sec  (Alex Turner, )
  Re: sustained update load of 1-2k/sec  (Ron, )
   Re: sustained update load of 1-2k/sec  ("Jeffrey W. Baker", )
    Re: sustained update load of 1-2k/sec  (Ron, )
   Re: sustained update load of 1-2k/sec  (Alex Turner, )
    Re: sustained update load of 1-2k/sec  (Ron, )
 Re: sustained update load of 1-2k/sec  ("J. Andrew Rogers", )
  Re: sustained update load of 1-2k/sec  (Mark Cotner, )

Andreas Pflug <> writes:
> Tom Lane wrote:
>> As far as the question "can PG do 1-2k xact/sec", the answer is "yes
>> if you throw enough hardware at it".  Spending enough money on the
>> disk subsystem is the key ...
>>
> The 1-2k xact/sec for MySQL seems suspicious, sounds very much like
> write-back cached, not write-through, esp. considering that heavy
> concurrent write access isn't said to be MySQLs strength...

> I wonder if preserving the database after a fatal crash is really
> necessary, since the data stored sounds quite volatile; in this case,
> fsync=false might be sufficient.

Yeah, that's something to think about.  If you do need full transaction
safety, then you *must* have a decent battery-backed-write-cache setup,
else your transaction commit rate will be limited by disk rotation
speed --- for instance, a single connection can commit at most 250 xacts
per second if the WAL log is on a 15000RPM drive.  (You can improve this
to the extent that you can spread activity across multiple connections,
but I'm not sure you can expect to reliably have 8 or more connections
ready to commit each time the disk goes 'round.)

            regards, tom lane


pgsql-performance by date:

From: Jeremiah Jahn
Date:
Subject: Re: extremly low memory usage
From: Jeremiah Jahn
Date:
Subject: Re: extremly low memory usage