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

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.


Pavan Deolasee

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to