Re: Block B-Tree concept

Tom Lane wrote:
> 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.

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".

Yeah. :-(

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

Good point. I didn't realize that before.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com