Thread: Checkpoints and buffers that are hint-bit-dirty

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.

I guess it doesn't really buy much, probably just a slight delay in writing
out the page until bgwriter gets around to it. Conceivably you could have a
hot buffer with many missing hint bits which will get written out on several
checkpoints but how many of those can you have? And extending the checkpoint
doesn't seem like much of a concern. On the other hand it wouldn't be hard to
check would it?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.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.
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.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