> 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
Hello Experts,
Our application has a database with a large number of partitioned tables
used to store time series data.
It is partitioned by time: new data is populated into the current
partition, old partitions eventually get dropped, and the partitions in
between are largely static.
I had not
