Re: Resurrecting per-page cleaner for btree

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> > This is a revised patch originated by Junji TERAMOTO for HEAD.
> > [BTree vacuum before page splitting]
> > http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> > I think we can resurrect his idea because we will scan btree pages
> > at-atime now; the missing-restarting-point problem went away.
> > Have I missed something? Comments welcome.
>
> I think the only serious objection to this would be that it'd mean that
> tuples that should have an index entry might not have one. The current
> form of VACUUM does not care, but people keep raising the idea of doing
> "retail" vacuuming that operates by looking up index entries explicitly.
> You could certainly make a retail vacuumer do nothing if it fails to
> find the expected index entry, but ISTM that'd be a rather serious loss
> of consistency checking --- you could not tell the someone-already-
> deleted-it case apart from a bug in the vacuumer's index value
> computation or lookup.

Well you already have that case anyways due to online index builds. (If a
vacuum gets in between the two transactions.) I suppose you could go and check
whether the pg_index entry for the index indicates that it's valid already but
that's not something anyone has to be looking for currently.

> Personally I don't think retail vacuuming in that form will ever fly
> anyway, so I have no problem with installing the proposed patch,
> but I thought I'd better throw this comment out to see if anyone
> thinks it's a big deal.

Well it's not like the existing vacuum checks for this. It's not even
convenient to check for it in the current vacuum architecture. It would have
to maintain the list of expired htids that haven't been found yet in the
bulkdelete and see if there are any left when it's done.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com