From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Partial vacuum versus pg_class.reltuples |
Date: | 2009-06-07 18:11:58 |
Message-ID: | 603c8f070906071111v23d0315as318ad375b1ec8b6b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 6, 2009 at 3:44 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-06-07 18:37:59 | Re: Partial vacuum versus pg_class.reltuples |
Previous Message | Robert Haas | 2009-06-07 17:56:56 | Re: pg_migrator issue with contrib |