| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-02-01 18:09:44 | Re: log_hostname and pg_stat_activity |
| Previous Message | Jeff Davis | 2011-02-01 17:51:04 | Re: SSI patch version 14 |