Re: Optional skipping of unchanged relations during ANALYZE?

>> >> I am wondering if we should take the current SQL used by vacuumdb to
>> >> find missing stats and perform direct syscache lookups in C?
>> >
>> >
>> > So....about that. The exiting missing-stats-only queries test for a corresponding
>> > pg_statistic_ext_data row for any pg_statistic_ext row that meets the relation filters,
>> > but at this very moment we can restore all types of extended stats _except_ expressions.
>> > That functionality could make it into 19, but if it doesn't we're going to have to adjust
>> > vacuumdb to probe pg_statistic_ext.stxkeys for expression indexes and look for
>> > matching stxdexprs elements. I agree that those matches are better done with
>> > syscache lookups, but the SQL that we're treating as a spec might be a moving
>> > target in the near future.
>>
>> Eventually we will want vacuumdb to use the "ANALYZE (MISSING_STATS)" command
>> directly, rather than the SQL, but until the restore functionality
>> works for extended stats
>> of expressions, we will need to keep those separated. Did I understand
>> that correctly?
>
>
> Yes, but no, but yes (eventually). :)
>
> Yes, if we implemented ANALYZE(MISSING_STATS_ONLY), then yes, we'd want to leverage
> that that in vacuumdb once we know what versions it is available for, as what constitutes "missing"
> will change from version to version, and it would be nice to insulate vacuumdb from that. It will have
> to account for what "missing" meant in past versions though.

of course, because vacuumdb is a client tool, and can connect to any
version. So, vacuumdb will need
to check for server version and either run
"ANALYZE(MISSING_STATS_ONLY)" or the full SQL.

> But before we get there, we have to contend with the fact that what constitutes "missing" has already
> subtly changed since v18, that change is not yet reflected in vacuumdb, and ideally the definition
> would change back to the v18 definition before v19 feature freeze, but that isn't guaranteed.

OK, I am confused a bit about the details of this point, but it looks
like this work is happening
in another thread, maybe [0] ?

So with regards to this thread, vacuumdb using this new option will be
out of scope. This could
be handled in a future thread.

[0] https://www.postgresql.org/message-id/aRrHBj7I4CeV21dj@paquier.xyz

--
Sami Imseih
Amazon Web Services (AWS)