Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
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.
I'm not worried about getting different results. If a used-defined
function behaves badly, you're queries are screwed anyway. But throwing
an error would be bad, because that would abort the whole vacuum.
If we want to keep the property that VACUUM doesn't re-evaluate index
entries, any proposal that doesn't keep track of every heap tuple isn't
going to work. I'll try to modify the design I had in mind so that it
does keep track of every heap tuple in some form.
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
Good point. I didn't realize that before.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly