| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Spread checkpoint sync |
| Date: | 2011-01-31 17:11:24 |
| Message-ID: | 18624.1296493884@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 31, 2011 at 11:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wonder whether it'd be useful to keep track of the total amount of
>> data written-and-not-yet-synced, and to issue fsyncs often enough to
>> keep that below some parameter; the idea being that the parameter would
>> limit how much dirty kernel disk cache there is. Of course, ideally the
>> kernel would have a similar tunable and this would be a waste of effort
>> on our part...
> It's not clear to me how you'd maintain that information without it
> turning into a contention bottleneck.
What contention bottleneck? I was just visualizing the bgwriter process
locally tracking how many writes it'd issued. Backend-issued writes
should happen seldom enough to be ignorable for this purpose.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-01-31 17:14:18 | windows build docs |
| Previous Message | Robert Haas | 2011-01-31 17:04:00 | Re: Spread checkpoint sync |