| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
| Cc: | "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |
| Date: | 2007-06-07 22:46:17 |
| Message-ID: | 87lkeve62u.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:
> Gregory Stark wrote:
>
> > is it possible it's related to the performance drop immediately
> > following a vacuum analyze we've been seeing?
>
> I don't think so, unless you were counting on pgstats data of shared
> tables for something. The optimizer, for one, doesn't, so I doubt it
> would affect query planning. And it would only affect you if your
> queries were using shared tables, which I very much doubt ...
Does anything use the pgstats data for anything other than presenting feedback
to users?
Autovacuum uses it to estimate when tables should be vacuumed right? This
wouldn't have caused autovacuum to go nuts vacuuming these tables would it?
But I doubt even then that it could consume much i/o bandwidth.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-06-08 01:12:31 | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |
| Previous Message | Alvaro Herrera | 2007-06-07 22:09:36 | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2007-06-07 23:31:11 | Re: TOAST usage setting |
| Previous Message | Alvaro Herrera | 2007-06-07 22:35:31 | Re: Best Practice for running vacuums during off hours WAS Re: Autovacuum launcher doesn't notice death of postmaster immediately |