Skip site navigation (1) Skip section navigation (2)

Re: Spread checkpoint sync

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Greg Smith" <greg(at)2ndquadrant(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Itagaki Takahiro" <itagaki(dot)takahiro(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spread checkpoint sync
Date: 2011-02-01 17:58:52
Message-ID: 4D47F57C020000250003A0F5@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
 
> I also think Bruce's idea of calling fsync() on each relation just
> *before* we start writing the pages from that relation might have
> some merit.
 
What bothers me about that is that you may have a lot of the same
dirty pages in the OS cache as the PostgreSQL cache, and you've just
ensured that the OS will write those *twice*.  I'm pretty sure that
the reason the aggressive background writer settings we use have not
caused any noticeable increase in OS disk writes is that many
PostgreSQL writes of the same buffer keep an OS buffer page from
becoming stale enough to get flushed until PostgreSQL writes to it
taper off.  Calling fsync() right before doing "one last push" of
the data could be really pessimal for some workloads.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-02-01 18:09:44
Subject: Re: log_hostname and pg_stat_activity
Previous:From: Jeff DavisDate: 2011-02-01 17:51:04
Subject: Re: SSI patch version 14

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group