Re: pgsql: autovacuum: handle analyze for partitioned tables

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: pgsql: autovacuum: handle analyze for partitioned tables
Дата
Msg-id 20210422174346.GE7256@telsasoft.com
обсуждение исходный текст
Ответ на Re: pgsql: autovacuum: handle analyze for partitioned tables  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: pgsql: autovacuum: handle analyze for partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Wed, Apr 21, 2021 at 07:06:49PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-09, Robert Haas wrote:
> > Does this need to worry about new partitions getting attached to a
> > partitioned table, or old ones getting detached? (Maybe it does
> > already, not sure.)
> 
> I was pinged because this is listed as an open item.  I don't think it
> is one.  Handling ATTACH/DETACH/DROP is important for overall
> consistency, of course, so we should do it eventually, but the fact that
> autovacuum runs analyze *at all* for partitioned tables is an enormous
> step forward from it not doing so.  I think we should treat ATTACH/
> DETACH/DROP handling as a further feature to be added in a future
> release, not an open item to be fixed in the current one.

I think this is okay, with the caveat that we'd be changing the behavior
(again) in a future release, rather than doing it all in v14.

Maybe the behavior should be documented, though.  Actually, I thought the
pre-existing (non)behavior of autoanalyze would've been documented, and we'd
now update that.  All I can find is this:

https://www.postgresql.org/docs/current/sql-analyze.html
|The autovacuum daemon, however, will only consider inserts or updates on the
|parent table itself when deciding whether to trigger an automatic analyze for
|that table

I think that should probably have been written down somewhere other than for
the manual ANALYZE command, but in any case it seems to be outdated now.

-- 
Justin



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_identify_object_as_address() doesn't support pg_event_trigger oids
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Converting NOT IN to anti-joins during planning