Re: synchronous commit vs. hint bits

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, simon@2ndquadrant.com
Date: 2011-12-01T14:18:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Allow hint bits to be set sooner for temporary and unlogged tables.

On Thursday, December 01, 2011 03:11:43 PM Robert Haas wrote:
> 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. 
But it will slow down overall system io. For one an fsync() on linux will 
cause a queue drain on the io submit queue. For another it counts against the 
total available random io ops a device can do.
Which in turn will cause slowdown for anything else doing syncronous random 
io. I.e. read(2).

> 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.
Oh, that part I dont doubt. Sorry for that.


Andres