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

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/>