On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund <andres@anarazel.de> wrote:
>> Oh, that's interesting. Why do you want to avoid frequent fsyncs? I
>> thought the point of synchronous_commit=off was to move the fsyncs to
>> the background, but not necessarily to decrease the frequency.
> Is that so? If it wouldn't avoid fsyncs how could you reach multiple thousand
> TPS in a writing pgbench run on a pretty ordinary system with fsync=on?
Eh, well, what would stop you from achieving that? An fsync operation
that occurs in the background doesn't block further transactions from
completing. Meanwhile, getting the WAL records on disk faster allows
us to set hint bits sooner, which is a significant win, as shown by
the numbers I posted upthread.
One possible downside of trying to kick off the fsync more quickly is
that if there are a continuous stream of background fsyncs going on, a
process that needs to do an XLogFlush in the foreground (i.e. a
synchronous_commit=on transaction in the middle of many
synchronous_commit=off transactions) might be more likely to find an
fsync already in progress and therefore need to wait until it
completes before starting the next one, slowing things down. But I'm
a bit reluctant to believe that is a real effect without some data.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
