Re: Dead Space Map - Mailing list pgsql-hackers

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> Vacuum will need to be modified to use index lookups to find index tuples 
> corresponding the dead heap tuples. Otherwise you have to scan through 
> all the indexes anyway.

This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
index involving a user-written function that was claimed to be immutable
and is not.  There are concurrency-safety issues too, I think, having to
do with the way that btree ensures we don't delete any index tuple that
some scan is stopped on.

> * vacuuming pages one by one as they're written by bgwriter

That's not happening.  VACUUM has to be a transaction and the bgwriter
does not run transactions; nor is it in any position to clean out index
entries associated with a heap page.  (To change this would at a minimum
require instituting a separate bgwriter process per database; or else a
wholesale rewrite of our catalog access infrastructure to allow it to
work in a non-database-specific context.  There are also interesting
deadlock problems to think about if the bgwriter can be blocked by other
transactions, or if it needs to read pages not currently in shared memory.)

> * implementation of index-only scans

> An index scan would not have to check the visibility information of heap 
> tuples on those heap pages that are marked as clean in the dead space map.
> This requires that the dead space map is implemented so that a page is 
> reliably marked as dirty in all circumstances when it contains any tuples 
> that are not visible to all backends.

The "reliably" part of this is likely to make it a non-starter.  Another
problem is that the semantics needed by this are not quite the same as
the semantics of whether a page needs to be visited by vacuum.

> My current implementation stores a bitmap of 32k bits in the special space 
> of every 32k heap pages. Each bit in the bitmap corresponds one heap page. 
> The bit is set every time a tuple is updated, and it's cleared by vacuum. 
> This is a very simple approach, and doesn't take much space.

I thought the plan was to use out-of-line storage associated with each
table "segment" file.
        regards, tom lane