Re: ANALYZE ONLY - Mailing list pgsql-hackers

From Ilia Evdokimov
Subject Re: ANALYZE ONLY
Date
Msg-id bc1eb1bb-7ac1-4b0c-81a7-a16a18dfcb05@tantorlabs.com
Whole thread Raw
In response to Re: ANALYZE ONLY  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: ANALYZE ONLY
List pgsql-hackers

On 20.8.24 10:42, Jelte Fennema-Nio wrote:

On Tue, 20 Aug 2024 at 07:52, Michael Harris <harmic@gmail.com> wrote:
  1. Would such a feature be welcomed? Are there any traps I might not
have thought of?
I think this sounds like a reasonable feature.


  2. The existing ANALYZE command has the following structure:
     ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
     It would be easiest to add ONLY as another option, but that
doesn't look quite     right to me - surely the ONLY should be attached to the table name?     An alternative would be:
     ANALYZE [ ( option [, ...] ) ] [ONLY] [ table_and_columns [, ...] ]

Any feedback or advice would be great.
Personally I'd prefer a new option to be added. But I agree ONLY isn't
a good name then. Maybe something like SKIP_PARTITIONS.


Hi everyone,

Your proposal is indeed interesting, but I have a question: can't your issue be resolved by properly configuring autovacuum instead of developing a new feature for ANALYZE?

From my perspective, ANALYZE is intended to forcibly gather statistics from all partitioned tables. If the goal is to ensure that statistics are updated at the right moment, adjusting the autovacuum_analyze_threshold and autovacuum_analyze_scale_factor parameters might be the solution.

-- 
Regards,
Ilia Evdokimov,
Tantor Labs LCC.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication
Next
From: Maxim Orlov
Date:
Subject: Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points