Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options - Mailing list pgsql-performance

From Tom Lane
Subject Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Date
Msg-id 28518.1095127259@sss.pgh.pa.us
Whole thread Raw
In response to Re: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-performance
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If we had a majority of queries filling more than one block we would
> be checkpointing like crazy and we don't normally get reports about
> that.

[ raised eyebrow... ]  And of course the 30-second-checkpoint-warning
stuff is a useless feature that no one ever exercises.

But your logic doesn't hold up anyway.  People may be doing large
transactions without necessarily doing them back-to-back-to-back;
there could be idle time in between.  For instance, I'd think an average
transaction size of 100 blocks would be more than enough to make fsync a
winner.  There are 2K blocks per WAL segment, so 20 of these would fit
in a segment.  With the default WAL parameters you could do sixty such
transactions per five minutes, or one every five seconds, without even
causing more-frequent-than-default checkpoints; and you could do two a
second without setting off the checkpoint-warning alarm.  The lack of
checkpoint complaints doesn't prove that this isn't a common real-world
load.

            regards, tom lane

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Large # of rows in query extremely slow, not using index
Next
From: Mischa Sandberg
Date:
Subject: Re: Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables