Skip site navigation (1) Skip section navigation (2)

Re: Block B-Tree concept

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block B-Tree concept
Date: 2006-09-28 11:55:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Mike BassettDate: 2006-09-28 13:22:16
Subject: Install on Windows XP
Previous:From: Gevik BabakhaniDate: 2006-09-28 10:40:07
Subject: casting to domain problem.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group