Re: pgsql: autovacuum: handle analyze for partitioned tables - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: pgsql: autovacuum: handle analyze for partitioned tables
Date
Msg-id 20210422174346.GE7256@telsasoft.com
Whole thread Raw
In response to Re: pgsql: autovacuum: handle analyze for partitioned tables  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pgsql: autovacuum: handle analyze for partitioned tables
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_identify_object_as_address() doesn't support pg_event_trigger oids
Next
From: Andy Fan
Date:
Subject: Re: Converting NOT IN to anti-joins during planning