Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal
Дата
Msg-id AANLkTinPZTY3dwaCcabRNKfM2xwo_a2O=aDaqiMCdZuV@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal  (Jim Nasby <Jim@Nasby.net>)
Список pgsql-hackers
On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus <josh@agliodbs.com> wrote:
> For example, imagine if the hint bits were moved to a separate per-table
> bitmap outside the table instead of being stored with each row, as the
> current FSM is.

How many times do we have to keep going around the same block?

We *already* have separate bitmap outside the table for transaction
commit bits. It's the clog.

The only reason the hint bits exist is to cache that so we don't need
to do extra I/O to check tuple visibility. If the hint bits are moved
outside the table then they serve no purpose whatsover. Then you have
an additional I/O to attempt to save an additional I/O.

The only difference between the clog and your proposal is that the
clog is two bits per transaction and your proposal is 4 bits per
tuple. The per-tuple idea guarantees that the extra I/O will be very
localized which isn't necessarily true for the clog but the clog is
small enough that it probably is true anyways. And even if there's no
I/O the overhead to consult the clog/per-table fork in memory is
probably significant.


-- 
greg


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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: wCTE behaviour
Следующее
От: Tom Lane
Дата:
Сообщение: Re: wCTE behaviour