Re: Visibility map thoughts - Mailing list pgsql-hackers

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:

> One problem is that you have to atomically update the visibility map when
> you update the heap. That means that you have to lock the visibility map
> page and the heap page at the same time. If the visibility map is in the
> heap, you need to take care that you don't deadlock.

Well that's still a problem if it's in another filenode.

On the other hand if you allocate a whole byte to every page you could set it
atomically and not have to lock the page. Effectively having the lock on the
original page protect the info byte. Whereas setting a single bit requires
protecting against someone setting one of the other bits corresponding to
another page entirely.

>>> - We don't need to clear the bit on HOT updates, because by definition none
>>> of the indexed columns changed.
>>
>> Huh?  I don't think I believe that, and I definitely don't believe your
>> argument for it.
>
> HOT-updating a row doesn't change what an index-only scan would see. An
> index-only scan only needs columns that are in the index, and since it's a HOT
> update, none of those columns have changed, so it doesn't matter which tuple
> we're returning them from.
>
> Pages that have HOT updated tuples, but haven't otherwise been modified since
> last vacuum are also not interesting for VACUUM, because a prune will do the
> job of getting rid of dead HOT-updated tuples just as well.
>
> Am I missing something?

I think the point is that for index-only scans you really just want to know
the visibility of the whole chain. The whole chain is either known-visible or
not. A HOT update doesn't change that, it just changes which version along the
chain is visible and the values of the non-indexed columns in that version.

Some thought has to be given to the transition stages when you create or drop
an index but I don't see a problem there. If you have a "broken" hot chain it
doesn't change the visibility rules for anyone who does use an old index (and
nobody who could see the broken end of the chain should be using the new index
anyways).

The problem with this is that it's different from what a DSM would need. We
could skip vacuuming such HOT updated dead tuples, assuming a page prune will
get it the next time we access the page I suppose. Or we could use a separate
bit for more aggressive vacuum information.


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!