From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Checkpoints and buffers that are hint-bit-dirty |
Date: | 2007-07-09 03:20:01 |
Message-ID: | 87abu6clge.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> When we checkpoint we write out all dirty buffers. But ISTM we don't really
>> need to write out buffers which are dirty but which have an LSN older than the
>> previous checkpoint. Those represent buffers which were dirtied by a
>> non-wal-logged modification, ie, hint bit setting. The other non-wal-logged
>> operations will sync the buffer themselves when they're done.
>
> In the current dispensation we don't really care how long a checkpoint
> takes, so I don't see the advantage to be gained.
I agree that just a shifting of i/o to the checkpoint from bgwriter isn't
interesting.
Saving i/o is still i/o saved -- if it doesn't shorten the checkpoint it
reduces its i/o bandwidth demands. But again, I couldn't come up with any
realistic scenario where the actual i/o saved is anything more than a token
amount. I thought I would toss the idea up in case I was missing something.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | rupesh bajaj | 2007-07-09 09:36:58 | Re: Implementation of new operators inside the PostgreSQL |
Previous Message | Tom Lane | 2007-07-09 01:46:41 | Re: PQescapeBytea* version for parameters |