<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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(at)agliodbs(dot)com> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">For example, imagine if the hint bits were moved to a separate per-table<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">bitmap outside the table instead of being stored with each row, as the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">current FSM is.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">How many times do we have to keep 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">commit bits. It's the clog.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The only reason the hint bits exist is to cache that so we don't need<br></blockquote><blockquote type="cite">to do extra I/O to check tuple visibility. If the hint bits are moved<br></blockquote><blockquote type="cite">outside the table then they serve no purpose whatsover. Then you have<br></blockquote><blockquote type="cite">an additional I/O to attempt to save an additional I/O.<br></blockquote><br>Are you sure hint bits are only for 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* have to worry about CLOG IO, and there's probably a lot of ways around that (memory mapping CLOG is one possibility), especially considering that 4G isn't exactly a large amount of memory these days.<br>--<br>Jim C. Nasby, Database Architect jim(at)nasby(dot)net<br>512.569.9461 (cell) http://jim.nasby.net<br><br><br></body></html>