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. The index entry
would eventually point to a wrong table entry, after the table item slot
gets recycled for another tuple.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
