> You could probably do some sampling of the pg_stat_progress_analyze
> view to figure out what's taking the most time.
I did another run, sampling the pg_stat_progress_analyze every 30s.
For the first 4 minutes it was working on the partitioned table.
After that it began analyzing all the parti
On Wed, 7 Aug 2024 at 19:20, Michael Harris wrote:
> I found that running an ANALYZE specifying only those 4 columns only took
> 5 minutes, compared to the 30 minutes for the whole table.
>
> That was a bit of a surprise as I imagined actually reading the table would
> take
> most of the time and
Many thanks David for the comprehensive response.
> I think the complaint was about no autovacuum on the partitioned
> table, not the partitions.
Yes, exactly.
One other piece of information: these tables contain a lot of columns, of which
only 4 are normally used for WHERE clauses or joins. The
On Wed, 7 Aug 2024 at 16:44, Christophe Pettus wrote:
> Child partitions should be autovacuumed and autoanalyzed just like any other
> table; they are not prohibited from autovacuum in any way by default. It's
> probably a good idea to investigate why they are not being picked up by
> autovacu
> On Aug 6, 2024, at 21:13, Michael Harris wrote:
>
> 1. What is the consequence of not having good statistics on partitioned
> table level, if you do have good statistics on the partition level?
The child partitions are just tables, and all of the same issues that can arise
from bad stat
