On Mon, Jul 09, 2001 at 07:25:33PM -0400, Tom Lane wrote:
> substantial baggage. (In addition to the statement itself, there's
> cruft in each instance of index build to deal with EXTEND. All that
> stuff should come out IMHO.)
Actually, there is far, far more code to come out. There are complete
functions which need to be removed. That's why I suggested leaving that to a
separate patch.
> I suspect you need to run cnfify after and-ing together the predicate
> and index quals. clauselist_selectivity assumes it's working on
> cnf'ified expressions.
OK. Do I need to worry about that function destroying either of the input
lists?
> You didn't provide context in which to decode Var references. See
> deparse_context_for(). The SQL function will need to take a relation
> name (or OID? not sure which is preferable) as well as the compiled
> predicate. Btw, don't set forceprefix true; we don't need that if
> there's only going to be one relation involved.
Oh. So the Var references in the tree are not linked to any particular
table? I understand then. deparse_context_for() takes both an oid and a
relation name so I'd need a name_to_oid or oid_to_name function.
> > * VACUUM still complains about tuple count mismatch. Anyone have a good idea
> > on how to deal with this?
>
> I'd be inclined to just weaken VACUUM's test from "=" to "<=" whenever
> the index has a predicate.
I'll have to check again, but I thought that the VACUUM code only had the
OID of the index, so how it is supposed to work out if it's a partial index.
I'll look at this again tonight.
Thanks for your feedback,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
> It would be nice if someone came up with a certification system that
> actually separated those who can barely regurgitate what they crammed over
> the last few weeks from those who command secret ninja networking powers.