From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, simon(at)2ndquadrant(dot)com |
Subject: | Re: synchronous commit vs. hint bits |
Date: | 2011-12-01 14:18:29 |
Message-ID: | 201112011518.29964.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, December 01, 2011 03:11:43 PM Robert Haas wrote:
> On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikko Tiihonen | 2011-12-01 14:42:43 | Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility |
Previous Message | karavelov | 2011-12-01 14:12:03 | Re: Why so few built-in range types? |