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

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal
Дата
Msg-id 7FC2D2C0-C100-460C-A2E3-9090A449C025@Nasby.net
обсуждение исходный текст
Ответ на Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On Nov 14, 2010, at 3:40 PM, Greg Stark wrote:<br /><blockquote type="cite">On Sun, Nov 14, 2010 at 8:52 PM, Josh
Berkus<josh@agliodbs.com> wrote:<br /></blockquote><blockquote type="cite"><blockquote type="cite">For example,
imagineif the hint bits were moved to a separate per-table<br /></blockquote></blockquote><blockquote
type="cite"><blockquotetype="cite">bitmap outside the table instead of being stored with each row, as the<br
/></blockquote></blockquote><blockquotetype="cite"><blockquote type="cite">current FSM is.<br
/></blockquote></blockquote><blockquotetype="cite"><br /></blockquote><blockquote type="cite">How many times do we have
tokeep going around the same block?<br /></blockquote><blockquote type="cite"><br /></blockquote><blockquote
type="cite">We*already* have separate bitmap outside the table for transaction<br /></blockquote><blockquote
type="cite">commitbits. It's the clog.<br /></blockquote><blockquote type="cite"><br /></blockquote><blockquote
type="cite">Theonly reason the hint bits exist is to cache that so we don't need<br /></blockquote><blockquote
type="cite">todo extra I/O to check tuple visibility. If the hint bits are moved<br /></blockquote><blockquote
type="cite">outsidethe table then they serve no purpose whatsover. Then you have<br /></blockquote><blockquote
type="cite">anadditional I/O to attempt to save an additional I/O.<br /></blockquote><br />Are you sure hint bits are
onlyfor IO savings? Calculating visibility from CLOG involves a hell of a lot more CPU than checking a hint bit.<br
/><br/>It would be extremely interesting if the CPU overhead wasn't very noticeable however. That would mean we *only*
haveto worry about CLOG IO, and there's probably a lot of ways around that (memory mapping CLOG is one possibility),
especiallyconsidering that 4G isn't exactly a large amount of memory these days.<br />--<br />Jim C. Nasby, Database
Architect                  jim@nasby.net<br />512.569.9461 (cell)                         http://jim.nasby.net<br /><br
/><br/> 

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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: wal_sender_delay is still required?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: wal_sender_delay is still required?