On Fri, Mar 25, 2011 at 10:34 AM, Jim Nasby <j...@nasby.net> wrote: > On Mar 25, 2011, at 9:52 AM, Merlin Moncure wrote: >> Without this bit, the only way to set hint bits going during bufmgr >> eviction is to do a visibility check on every tuple, which would >> probably be prohibitively expensive. Since OLTP environments would >> rarely see this bit, they would not have to pay for the check. > > IIRC one of the biggest costs is accessing the CLOG, but what if the > bufmgr.c/bgwriter didn't use the same CLOG lookup mechanism as backends did? > Unlike when a backend is inspecting visibility, it's not necessary for > something like bgwriter to know exact visibility as long as it doesn't mark > something as visible when it shouldn't. If it uses a different CLOG > caching/accessing method that lags behind the real CLOG then the worst-case > scenario is that there's a delay on setting hint bits. But getting grwiter to > dothis would likely still be a huge win over forcing backends to worry about > it. It's also possible that the visibility check itself could be simplified. > > BTW, I don't think you want to play these games when a backend is evicting a > page because you'll be slowing a real backend down.
Well, I'm not so sure -- as noted above, you only pay for the check above when all the records in a page are new, and only once per page, not once per tuple. Basically, only when you are bulk jamming records through the buffers. The amoritized cost of the clog lookup is going to be near zero (maybe you could put a fuse in that would get tripped if there weren't enough tuples in the page to justify the check). If you are bulk loading more data than you have shared buffers, then you get zero benefit. However, you might having the makings of a strategy of dealing with hint bit i/o in user land. (by breaking up transactions, tweaking shared buffers, etc). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
