Re: [PATCHES] Resurrecting per-page cleaner for btree - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Resurrecting per-page cleaner for btree
Date
Msg-id 2220.1153927791@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Resurrecting per-page cleaner for btree  (Gregory Stark <gsstark@mit.edu>)
Responses Re: [PATCHES] Resurrecting per-page cleaner for btree  (Csaba Nagy <nagy@ecircle-ag.com>)
Re: [PATCHES] Resurrecting per-page cleaner for btree  (Jim Nasby <jnasby@pervasive.com>)
List pgsql-hackers
Gregory Stark <gsstark@mit.edu> writes:
> ... Well it's not like the existing vacuum checks for this.

Right, that's exactly why the patch works at all.  But the point here is
that the existing vacuum does not rely on re-computing index keys; all
it cares about is matching TIDs.  The retail-vacuum idea depends on the
assumption that you can look at the tuple and re-compute the same index
keys that you computed the first time; which is an assumption much
shakier than the assumption that TID comparison works.  (In fact, it's
trivial to see how user-defined functions that are mislabeled immutable
could make this fail.)  So retail vacuum without any cross-check that
you got all the index tuples is a scary proposition IMHO.

            regards, tom lane

pgsql-hackers by date:

Previous
From: andrew@dunslane.net
Date:
Subject: Re: pgbench enhancements
Next
From: Tom Lane
Date:
Subject: Re: Refactoring the API for amgetmulti