pg_dump --dbname=src2 --table=tenk1 --statistics-only --verbose > x.sql there no pg_restore_attribute_stats, pg_restore_relation_stats there for table tenk1. There aren't any statistics, should there be?
pg_restore_relation_stats: yes. looking into that. pg_restore_attribute_stats: yes IF the table had been analyzed, no otherwise.
also should pg_dump --dbname=src2 --no-data --no-schema --table=tenk1 dump the statistics? currently seems no.
in doc/src/sgml/ref/pg_dump.sgml there are six options to control the main output now. --schema-only, --statistics-only, --data-only, --no-schema, --no-data, --no-statistics maybe we need spare one paragraph to explain the default behavior, and also have an example on it?
+1
pg_dump --dbname=src2 --table=tenk1 --verbose > 1.sql seems the statistics dump (pg_restore_attribute_stats) is ordered by attribute name. should it make more sense to order by attnum?
For security reasons, we pull attribute statistics from pg_stats (https://www.postgresql.org/docs/current/view-pg-stats.html) which does not have attnum. The only reason we order the list is to ensure that dump comparison tests match.
getRelationStatistics typedef struct _relStatsInfo { DumpableObject dobj; char relkind; /* 'r', 'v', 'c', etc */ bool postponed_def; } RelStatsInfo; comment /* 'r', 'v', 'c', etc */ Is it wrong? there is no relkind='c'.
Yeah, I think 'c' should be an 'm' there.
field postponed_def really deserves a comment.
Can do.
we also need change enum dbObjectTypePriorities static const int dbObjectTypePriority[] ?
We'd need two entries, because that enum includes PRIO_PRE_DATA_BOUNDARY and PRIO_POST_DATA_BOUNDARY, and statistics can either be in DATA or POST_DATA.
in dumpRelationStats, we can add Assert on it. if (!fout->dopt->dumpStatistics) return; Assert(dobj->dump & DUMP_COMPONENT_STATISTICS);
I found out the owner's info is missing in the dumped content. for example, the line "Name: STATISTICS DATA tenk1_pkey;" missing owner info. not sure this is intended?
Good question. I'm not sure if we need it or not. If stats had an owner, it'd be the owner of the relation.
