Re: Block B-Tree concept

Heikki Linnakangas <heikki@enterprisedb.com> writes:
> AFAICS, we could disable the optimization and use a full-blown 
> transaction when vacuuming a table with a functional block index. 

No, we couldn't, or at least it's not merely a matter of reversing a
recent optimization.

The fundamental issue with all these proposals is the assumption that
you can re-compute the index entries at all.  VACUUM has never, ever,
depended on the assumption that it can re-evaluate index entries and
get the same answers as the original insertion did.  Now obviously
it should theoretically be able to do that, in a theoretical bug-free
world, but given that we allow user-defined functions in index
expressions that is a very hazardous assumption: you might get a
different answer.  Or an error.  The current VACUUM procedure is able
to clean up index entries correctly without any recalculation of the
index values, just matching of TIDs.  I think we'd be taking a serious
robustness hit if we abandon that property.

This is basically the same objection that I have to the occasional
proposals for "retail VACUUM".

BTW, it's not merely a problem for functional indexes: the
datatype-specific functions invoked while searching an index are also
hazards.
        regards, tom lane