Re: limiting hint bit I/O

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: limiting hint bit I/O
Дата
Msg-id AANLkTik51jXVpZByLg3OjB12gieeC82sJqV0jdTPBzCP@mail.gmail.com
обсуждение исходный текст
Ответ на Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Um, yeah, I think you're having a problem keeping all the ideas straight
>>> ;-).  The argument about forensics has to do with how soon we're willing
>>> to freeze tuples, ie replace the XID with a constant.  Not about hint
>>> bits.
>
>> Those things are related, though.  Freezing sooner could be viewed as
>> an alternative to hint bits.
>
> Freezing sooner isn't likely to reduce I/O compared to hint bits.  What
> that does is create I/O that you *have* to execute ... both in the pages
> themselves, and in WAL.

It depends on which way you tilt your head - right now, we rewrite
each table 3x - once to populate, once to hint, and once to freeze.
If the table is doomed to survive long enough to go through all three
of those, then freezing is better than hinting.  Of course, that's not
always the case, but people keep complaining about the way this shakes
out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Determining client_encoding from client locale
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Database file copy