Skip to content

Commit 7b10ddb

Browse files
nathan-bossarthari90
authored andcommitted
pg_dump: Fix query for gathering attribute stats on older versions.
Commit 9c02e3a taught pg_dump to retrieve attribute statistics for 64 relations at a time. pg_dump supports dumping from v9.2 and newer versions, but our query for retrieving statistics for multiple relations uses WITH ORDINALITY and multi-argument UNNEST(), both of which were introduced in v9.4. To fix, we resort to gathering statistics for a single relation at a time on versions older than v9.4. Per buildfarm member crake. Author: Corey Huinker <corey.huinker@gmail.com> Discussion: https://postgr.es/m/Z_BcWVMvlUIJ_iuZ%40nathan (cherry picked from commit f0d0083)
1 parent 7bb3deb commit 7b10ddb

File tree

1 file changed

+30
-8
lines changed

1 file changed

+30
-8
lines changed

src/bin/pg_dump/pg_dump.c

Lines changed: 30 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9996,6 +9996,16 @@ fetchAttributeStats(Archive *fout)
99969996
PGresult *res = NULL;
99979997
static TocEntry *te;
99989998
static bool restarted;
9999+
int max_rels = MAX_ATTR_STATS_RELS;
10000+
10001+
/*
10002+
* Our query for retrieving statistics for multiple relations uses WITH
10003+
* ORDINALITY and multi-argument UNNEST(), both of which were introduced
10004+
* in v9.4. For older versions, we resort to gathering statistics for a
10005+
* single relation at a time.
10006+
*/
10007+
if (fout->remoteVersion < 90400)
10008+
max_rels = 1;
999910009

1000010010
/* If we're just starting, set our TOC pointer. */
1000110011
if (!te)
@@ -10021,7 +10031,7 @@ fetchAttributeStats(Archive *fout)
1002110031
* This is perhaps not the sturdiest assumption, so we verify it matches
1002210032
* reality in dumpRelationStats_dumper().
1002310033
*/
10024-
for (; te != AH->toc && count < MAX_ATTR_STATS_RELS; te = te->next)
10034+
for (; te != AH->toc && count < max_rels; te = te->next)
1002510035
{
1002610036
if ((te->reqs & REQ_STATS) != 0 &&
1002710037
strcmp(te->desc, "STATISTICS DATA") == 0)
@@ -10134,14 +10144,26 @@ dumpRelationStats_dumper(Archive *fout, const void *userArg, const TocEntry *te)
1013410144
* sufficient to convince the planner to use
1013510145
* pg_class_relname_nsp_index, which avoids a full scan of pg_stats.
1013610146
* This may not work for all versions.
10147+
*
10148+
* Our query for retrieving statistics for multiple relations uses
10149+
* WITH ORDINALITY and multi-argument UNNEST(), both of which were
10150+
* introduced in v9.4. For older versions, we resort to gathering
10151+
* statistics for a single relation at a time.
1013710152
*/
10138-
appendPQExpBufferStr(query,
10139-
"FROM pg_catalog.pg_stats s "
10140-
"JOIN unnest($1, $2) WITH ORDINALITY AS u (schemaname, tablename, ord) "
10141-
"ON s.schemaname = u.schemaname "
10142-
"AND s.tablename = u.tablename "
10143-
"WHERE s.tablename = ANY($2) "
10144-
"ORDER BY u.ord, s.attname, s.inherited");
10153+
if (fout->remoteVersion >= 90400)
10154+
appendPQExpBufferStr(query,
10155+
"FROM pg_catalog.pg_stats s "
10156+
"JOIN unnest($1, $2) WITH ORDINALITY AS u (schemaname, tablename, ord) "
10157+
"ON s.schemaname = u.schemaname "
10158+
"AND s.tablename = u.tablename "
10159+
"WHERE s.tablename = ANY($2) "
10160+
"ORDER BY u.ord, s.attname, s.inherited");
10161+
else
10162+
appendPQExpBufferStr(query,
10163+
"FROM pg_catalog.pg_stats s "
10164+
"WHERE s.schemaname = $1[1] "
10165+
"AND s.tablename = $2[1] "
10166+
"ORDER BY s.attname, s.inherited");
1014510167

1014610168
ExecuteSqlStatement(fout, query->data);
1014710169

0 commit comments

Comments
 (0)