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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Checkpoints and buffers that are hint-bit-dirty
Дата
Msg-id 87abu6clge.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Checkpoints and buffers that are hint-bit-dirty  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PQescapeBytea* version for parameters
Следующее
От: "Simon Riggs"
Дата:
Сообщение: Re: tsearch2: language or encoding