| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Florian Helmberger <fh(at)25th-floor(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
| Date: | 2011-05-27 18:34:10 |
| Message-ID: | 17685.1306521250@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Still, maybe we don't have a better option. If it were me, I'd add an
> additional safety valve: use your formula if the percentage of the
> relation scanned is above some threshold where there's unlikely to be
> too much skew. But if the percentage scanned is too small, then don't
> use that formula. Instead, only update relpages/reltuples if the
> relation is now larger; set relpages to the new actual value, and
> scale up reltuples proportionately.
Ah, progress: now we're down to arguing about the size of the fudge
factor ;-). I'll do something involving derating the reliability
when the number is coming from VACUUM.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | sonnix | 2011-05-27 19:46:47 | Restore master from slave |
| Previous Message | Robert Haas | 2011-05-27 15:07:05 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-05-27 18:39:26 | Re: How can I check the treatment of bug fixes? |
| Previous Message | Tom Lane | 2011-05-27 18:19:25 | Re: How can I check the treatment of bug fixes? |