>> >> 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/[email protected] -- Sami Imseih Amazon Web Services (AWS)
