Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.
Date
Msg-id 87lkeve62u.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.  (Michael Fuhr <mike@fuhr.org>)
List pgsql-hackers
"Alvaro Herrera" <alvherre@commandprompt.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Best Practice for running vacuums during off hours WAS Re: Autovacuum launcher doesn't notice death of postmaster immediately
Next
From: Bruce Momjian
Date:
Subject: Re: TOAST usage setting