Re: Partitioning versus autovacuum - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Partitioning versus autovacuum
Date
Msg-id CAM-w4HPpUbgcQ1220_Chs_2nGh5Dw1gBiegem7MAHfPHCg+Oyw@mail.gmail.com
Whole thread Raw
In response to Partitioning versus autovacuum  (Greg Stark <stark@mit.edu>)
Responses Re: Partitioning versus autovacuum
List pgsql-hackers
Actually I did just find it in the To-do wiki:

Have autoanalyze of parent tables occur when child tables are modified


On Mon., Sep. 30, 2019, 1:48 p.m. Greg Stark, <stark@mit.edu> wrote:
So we now support `ANALYZE partitioned_table` which will gather statistics for the main table by gathering stats from all the partitions.

However as far as I can tell autovacuum will never actually trigger this analyze. Because we never generate any update records for the parent table in the statistics. Have I missed something?

I didn't find any discussion of this in the threads from when partitioning was committed but there were a lot of discussions and I could easily have missed it.

Is there a story for this? Some way to configure things so that autovacuum will analyze partitioned tables?

Or should we look at doing something? Maybe whether we analyze a child we should also update the parent -- and if there's no stats yet run analyze on it?

This may be a serious enough problem for users that it may warrant backpatching. Not having any stats is resulting in some pretty weird plans for us.

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: errbacktrace
Next
From: Alvaro Herrera
Date:
Subject: Re: Commit fest 2019-09