Re: Load distributed checkpoint

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Load distributed checkpoint
Date: 2006-12-11 21:58:17
Message-ID: 457D8018.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

>>> On Mon, Dec 11, 2006 at 3:31 PM, in message
<457DCE4D(dot)7090402(at)cheapcomplexdevices(dot)com>, Ron Mayer
<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
>
> One thing I do worry about is if both postgresql and the OS
> are both delaying write()s in the hopes of collapsing them
> at the same time. If so, this would cause both to be experience
> bigger delays than expected, and make checkpoints worse.

That is my concern. Letting 30 seconds worth of dirty pages accumulate
between checkpoints and then trying to smooth the writes within
checkpoint code seems like a doomed effort. Either we take over control
of everything, like many other products, and schedule it all ourselves,
or we push it out to the file system fairly quickly and let it do its
job. Let's not stand with one foot on the pier and one on the boat.

It is entirely possible that the current setup, where a delay of a
couple seconds may collapse several OS API calls, could have a
performance benefit; but, let's be clear that we're talking about saving
that overhead, not disk I/O.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message DANTE Alexandra 2006-12-12 09:17:53 PostgreSQL 8.2 : regression failures on IA-64
Previous Message Ron Mayer 2006-12-11 21:40:29 Re: Grouped Index Tuples

Browse pgsql-patches by date

  From Date Subject
Next Message Zeugswetter Andreas ADI SD 2006-12-12 09:22:05 Re: Load distributed checkpoint
Previous Message Ron Mayer 2006-12-11 21:31:57 Re: Load distributed checkpoint