Re: [PATCHES] Resurrecting per-page cleaner for btree - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Resurrecting per-page cleaner for btree
Date
Msg-id 10016.1153930144@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Resurrecting per-page cleaner for btree  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: [PATCHES] Resurrecting per-page cleaner for btree  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Csaba Nagy <nagy@ecircle-ag.com> writes:
>> [snip] (In fact, it's
>> trivial to see how user-defined functions that are mislabeled immutable
>> could make this fail.)  So retail vacuum without any cross-check that
>> you got all the index tuples is a scary proposition IMHO.

> Wouldn't work to restrict that kind of vacuum to only tables which have
> no indexes using user defined functions ?

Of course, we never have bugs in PG core.  Nope, doesn't happen ...

> I actually wonder if such a vacuum would be useful for my scenario,
> where I have some pretty big tables, and update a relatively small
> percentage of it. Would it be faster to run such a vacuum against the
> current one ?

So far, the case hasn't been made for retail vacuum even ignoring the
not-so-immutable-function risk.

            regards, tom lane

pgsql-hackers by date:

Previous
From: "Bort, Paul"
Date:
Subject: Re: Better name/syntax for "online" index creation
Next
From: "Bort, Paul"
Date:
Subject: Re: GUC with units, details