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

From Alvaro Herrera
Subject Re: pgsql: autovacuum: handle analyze for partitioned tables
Date
Msg-id 20210409213155.GA23912@alvherre.pgsql
Whole thread Raw
In response to Re: pgsql: autovacuum: handle analyze for partitioned tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: autovacuum: handle analyze for partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
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.)

Good question.  It does not.

I suppose you could just let that happen automatically -- I mean, next
time the partitioned table is analyzed, it'll scan all attached
partitions.  But if no tuples are modified afterwards in existing
partitions (a common scenario), and the newly attached partition
contains lots of rows, then only future rows in the newly attached
partition would affect the stats of the partitioned table, and it could
be a long time before that causes an analyze on the partitioned table to
occur.

Maybe a way to attack this is to send a the "anl_ancestors" message to
the collector on attach and detach, adding a new flag ("is
attach/detach"), which indicates to add not only "changes_since_analyze
- changes_since_analyze_reported", but also "n_live_tuples".

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
(Tom Lane)



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Processing btree walks as a batch to parallelize IO
Next
From: Justin Pryzby
Date:
Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables