Re: Autovacuum on partitioned table (autoanalyze)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Autovacuum on partitioned table (autoanalyze)
Дата
Msg-id 20210404225158.GA22303@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Autovacuum on partitioned table (autoanalyze)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
On 2021-Apr-04, Tomas Vondra wrote:

> In fact, one of the first posts in this threads links to this:
> 
> https://www.postgresql.org/message-id/4823.1262132964%40sss.pgh.pa.us
> 
> i.e. Tom actually proposed doing something like this back in 2009, so
> presumably he though it's desirable back then.
> 
> OTOH he argued against adding another per-table counter and proposed
> essentially what the patch did before, i.e. propagating the counter
> after analyze. But we know that may trigger analyze too often ...

Yeah, I think that's a doomed approach.  The reason to avoid another
column is to avoid bloat, which is good but if we end up with an
unworkable design then we know we have to backtrack on it.

I was thinking that we could get away with having a separate pgstat
struct for partitioned tables, to avoid enlarging the struct for all
tables, but if we're going to also include legacy inheritance in the
feature clearly that doesn't work.

-- 
Álvaro Herrera       Valdivia, Chile
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ADD COLUMN fast default
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: pg_amcheck contrib application