Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit5d6eac8

Browse files
pg_dump: Adjust reltuples from 0 to -1 for dumps of older versions.
Before v14, a reltuples value of 0 was ambiguous: it could eithermean the relation is empty, or it could mean that it hadn't yetbeen vacuumed or analyzed. (Commit3d351d9 taught v14 and newerto use -1 for the latter case.) This ambiguity allegedly can causethe planner to choose inefficient plans after restoring to v18 ornewer. To fix, let's just dump reltuples as -1 in that case. Thiswill cause some truly empty tables to be seen as not-yet-processed,but that seems unlikely to cause too much trouble in practice.Note that we could alternatively teach pg_restore_relation_stats()to translate reltuples based on the version argument, but sincethat function doesn't exist until v18, there's no particularadvantage to that approach. That is, there's no chance ofrestoring stats dumped from a pre-v14 server to another pre-v14server. Per discussion, the current policy is to fix pre-v18behavior differences during export and everything else duringimport.Commit9879105 fixed a similar problem for vacuumdb by removingthe check for reltuples != 0. Presumably we could reinstate thatcheck now, but I've chosen to leave it in place in case reltuplesisn't accurate. As before, processing some empty tables seemsrelatively harmless.Author: Hari Krishna Sunder <hari.db.pg@gmail.com>Reviewed-by: Jeff Davis <pgsql@j-davis.com>Reviewed-by: Corey Huinker <corey.huinker@gmail.com>Discussion:https://postgr.es/m/CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC%3DWh-VeW64A%40mail.gmail.com
1 parent1722d5e commit5d6eac8

File tree

1 file changed

+14
-1
lines changed

1 file changed

+14
-1
lines changed

‎src/bin/pg_dump/pg_dump.c

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10929,7 +10929,20 @@ dumpRelationStats_dumper(Archive *fout, const void *userArg, const TocEntry *te)
1092910929
appendStringLiteralAH(out, rsinfo->dobj.name, fout);
1093010930
appendPQExpBufferStr(out, ",\n");
1093110931
appendPQExpBuffer(out, "\t'relpages', '%d'::integer,\n", rsinfo->relpages);
10932-
appendPQExpBuffer(out, "\t'reltuples', '%s'::real,\n", rsinfo->reltuples);
10932+
10933+
/*
10934+
* Before v14, a reltuples value of 0 was ambiguous: it could either mean
10935+
* the relation is empty, or it could mean that it hadn't yet been
10936+
* vacuumed or analyzed. (Newer versions use -1 for the latter case.)
10937+
* This ambiguity allegedly can cause the planner to choose inefficient
10938+
* plans after restoring to v18 or newer. To deal with this, let's just
10939+
* set reltuples to -1 in that case.
10940+
*/
10941+
if (fout->remoteVersion < 140000 && strcmp("0", rsinfo->reltuples) == 0)
10942+
appendPQExpBufferStr(out, "\t'reltuples', '-1'::real,\n");
10943+
else
10944+
appendPQExpBuffer(out, "\t'reltuples', '%s'::real,\n", rsinfo->reltuples);
10945+
1093310946
appendPQExpBuffer(out, "\t'relallvisible', '%d'::integer",
1093410947
rsinfo->relallvisible);
1093510948

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp