Re: Block B-Tree concept

Heikki Linnakangas <heikki(at)enterprisedb(dot)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