Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > On Mon, 27 Feb 2006, Tom Lane wrote: > >> This strikes me as a fairly bad idea, because it makes VACUUM dependent > >> on correct functioning of user-written code --- consider a functional > >> index involving a user-written function that was claimed to be immutable > >> and is not. > > > If the user-defined function is broken, you're in more or less trouble > > anyway. > > Less. A non-immutable function might result in lookup failures (not > finding the row you need) but not in database corruption, which is what > would ensue if VACUUM fails to remove an index tuple.
Arguably the database is *already* broken once one has used a non-immutable function in index ops. "Failing to remove" is a condition that is easily detected, so one can flag the operator class as lossy (RECHECK) and actually fix that brokenness. > Moreover, you haven't pointed to any strong reason to adopt this > methodology. It'd only be a win when vacuuming pretty small numbers > of tuples, which is not the design center for VACUUM, and isn't likely > to be the case in practice either if you're using autovacuum. If you're > removing say 1% of the tuples, you are likely to be hitting every index > page to do it, meaning that the scan approach will be significantly > *more* efficient than retail lookups. One use-case would be keeping update-heavy databases healthy, by ensuring that most updates will end up in the same page as originals. That goal would be easier to achieve, if there were a process which reclaims old tuples as fast as possible. ----------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
