On Sun, Dec 16, 2012 at 11:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > And I agree with him that your proposed > redefinition of the bit's meaning to avoid that is pretty horrid; > it's ugly, complicates the invariant quite a lot, and breaks some > existing usages of the bit.
(slammed.. feels the pain) You definitely have better intuitions and understanding of the system than me and I've to be really shameful to defend my idea which was out of the hat anyways, but let me try nevertheless at the risk of being slammed again :-) So whats the current meaning of the VM bit ? If set, it tells us that all tuples in the page are visible to all current and future transactions. But thats not entirely true. Otherwise why wouldn't we mark a page all-visible if it contains a DEAD line pointer ? Of course, we don't do that to support index only scans and make sure that vacuum picks up such page. So would I be too wrong if I take liberty to read VM bit as: if set, every index pointer to the heap page is for sure pointing to *only* all-visible tuple. I also consider vacuum as an activity that is needed because we can't clean up dead line pointers in the heap without first removing the index pointers. So visibility maps go hand-in-hand with indexes. In fact, if a table does not have any index, I am not sure if we even need a VM for that table, especially if we can teach HOT prune to record free space with FSM. My half-cooked idea extends that and says: if VM bit is set, every index pointer to the heap page is pointing to either a all-visible tuple or a valid HOT-chain that has all-visible tuple at the end (aborted HOT tuples at the end are not counted as part of a valid chain). OTOH the page-level bit is set if every tuple in the heap page is all-visible. DEAD line pointers are not counted while arriving at page level bit. So in this new scheme of things, there is a loose correspondence between these two. VM bit is useful for index-only scans and vacuum optimisations while page-level bit has limited use of optimising heap scans. Andres probably said the same thing. Jeff Davis is already talking about removing the page-level bit on other threads, so I don't see much problem breaking a 1-to-1 mapping with the VM bit and the page-level bit. Having said all of this, I am not insisting on this unless we see a value in it. And there could be when you reach a steady state so that almost every update is a HOT update. Today you will still need periodic vacuums just so that index-only scans work. Of course, you talked about other code paths to set all-visible bits. > > If we decide that we don't want to restrict pruning like that, then > this patch probably has merit. But we can't evaluate the two issues > independently. > Fair enough. If someone starts actively working on moving HOT prune logic to the UPDATE path, I'll withdraw this patch. But any change to the HOT prune logic will require extensive and long duration testing to prove its value. After all, we spent hours testing it when we wrote it and had seen how small changes can cause drop in performance. If nobody is volunteering to do this change at the moment, I feel that the patch has value, as you yourself noted, and should be considered on its merits, as things stand today and not based on things that we might do in future. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
