On Tue, Sep 26, 2006 at 05:27:56PM +0100, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: > >Tom Lane wrote: > >>Anything that involves having VACUUM re-evaluate index expressions is a > >>nonstarter ... or have you already forgotten the optimizations we put > >>into 8.2 that assume, eg, no sub-transactions within a VACUUM? > > > >Umm, I'm afraid I have. Could you give me a clue? > I think I found it. Is this what you're talking about (in > commands/vacuum.c): > > /* > * During a lazy VACUUM we do not run any user-supplied functions, > * and so it should be safe to not create a transaction snapshot. > * > * We can furthermore set the inVacuum flag, which lets other > * concurrent VACUUMs know that they can ignore this one while > * determining their OldestXmin. (The reason we don't set inVacuum > * during a full VACUUM is exactly that we may have to run user- > * defined functions for functional indexes, and we want to make > * sure that if they use the snapshot set above, any tuples it > * requires can't get removed from other tables. An index function > * that depends on the contents of other tables is arguably broken, > * but we won't break it here by violating transaction semantics.) > * > * Note: the inVacuum flag remains set until CommitTransaction or > * AbortTransaction. We don't want to clear it until we reset > * MyProc->xid/xmin, else OldestXmin might appear to go backwards, > * which is probably Not Good. > */ > MyProc->inVacuum = true;
Do I understand that to mean that you can no longer lazy vacuum a functional index? -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
