Re: Partial vacuum versus pg_class.reltuples - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Partial vacuum versus pg_class.reltuples
Date
Msg-id 603c8f070906071111v23d0315as318ad375b1ec8b6b@mail.gmail.com
Whole thread Raw
In response to Partial vacuum versus pg_class.reltuples  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Partial vacuum versus pg_class.reltuples  (Greg Stark <stark@enterprisedb.com>)
Re: Partial vacuum versus pg_class.reltuples  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jun 6, 2009 at 3:44 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> I complained a couple days ago that in HEAD, vacuum is putting
> very bogus values into pg_class.reltuples for indexes:
> http://archives.postgresql.org/pgsql-bugs/2009-06/msg00037.php
>
> After looking through the code a bit, I've confirmed my prior guess that
> this is caused by the partial-vacuum patch.  The number that's being
> used is the number of live tuples found on the pages that were actually
> scanned.  There's a kluge in there to keep from storing this number as
> the relation's own reltuples, but the implications for indexes were not
> considered.  The index AMs generally assume that what they're told in
> IndexVacuumInfo.num_heap_tuples can be trusted, and that's not true
> anymore.
>
> I think probably the only workable solution for 8.4 is to use the prior
> value of the relation's reltuples field as num_heap_tuples when we have
> not scanned the whole heap.  This will effectively mean that index
> reltuples values don't change either in a partial vacuum.

Am I wrong to be frightened by the implications of updating this value
only once in a blue moon?  Doesn't this have the potential to result
in really bad plans?  Do we have any reasonable manual way of forcing
VACUUM to scan the entire heap?

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_migrator issue with contrib
Next
From: Greg Stark
Date:
Subject: Re: Partial vacuum versus pg_class.reltuples