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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.
Дата
Msg-id 87lkeve62u.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на 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.  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.  (Michael Fuhr <mike@fuhr.org>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Best Practice for running vacuums during off hours WAS Re: Autovacuum launcher doesn't notice death of postmaster immediately
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: TOAST usage setting