Re: [HACKERS] Resurrecting per-page cleaner for btree - Mailing list pgsql-patches

From Csaba Nagy
Subject Re: [HACKERS] Resurrecting per-page cleaner for btree
Date
Msg-id 1153928965.22367.110.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: [HACKERS] Resurrecting per-page cleaner for btree  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Resurrecting per-page cleaner for btree  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
> [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 ? That would mean a very small
restriction I guess, probably 99.9% of the indexes won't use user
defined functions...

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 ?
One example would be a ~100 million table where I have 1-4 million
updates per day. Could I run vacuum multiple times a day for this table
and expect that individual runs are relatively fast ?

Cheers,
Csaba.



pgsql-patches by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: LDAP lookup of connection parameters
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Resurrecting per-page cleaner for btree