aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/analyze.c
diff options
context:
space:
mode:
authorTomas Vondra <tomas.vondra@postgresql.org>2022-01-15 18:17:20 +0100
committerTomas Vondra <tomas.vondra@postgresql.org>2022-01-15 19:06:48 +0100
commit20b9fa308ebf7d4a26ac53804fce1c30f781d60c (patch)
tree92ae872e92ccf4f90f42cda6db34e13ede4d8651 /src/backend/commands/analyze.c
parent74527c3e022d3ace648340b79a6ddec3419f6732 (diff)
downloadpostgresql-20b9fa308ebf7d4a26ac53804fce1c30f781d60c.tar.gz
postgresql-20b9fa308ebf7d4a26ac53804fce1c30f781d60c.zip
Build inherited extended stats on partitioned tables
Commit 859b3003de disabled building of extended stats for inheritance trees, to prevent updating the same catalog row twice. While that resolved the issue, it also means there are no extended stats for declaratively partitioned tables, because there are no data in the non-leaf relations. That also means declaratively partitioned tables were not affected by the issue 859b3003de addressed, which means this is a regression affecting queries that calculate estimates for the whole inheritance tree as a whole (which includes e.g. GROUP BY queries). But because partitioned tables are empty, we can invert the condition and build statistics only for the case with inheritance, without losing anything. And we can consider them when calculating estimates. It may be necessary to run ANALYZE on partitioned tables, to collect proper statistics. For declarative partitioning there should no prior statistics, and it might take time before autoanalyze is triggered. For tables partitioned by inheritance the statistics may include data from child relations (if built 859b3003de), contradicting the current code. Report and patch by Justin Pryzby, minor fixes and cleanup by me. Backpatch all the way back to PostgreSQL 10, where extended statistics were introduced (same as 859b3003de). Author: Justin Pryzby Reported-by: Justin Pryzby Backpatch-through: 10 Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
Diffstat (limited to 'src/backend/commands/analyze.c')
-rw-r--r--src/backend/commands/analyze.c18
1 files changed, 17 insertions, 1 deletions
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index cc9705d06bf..d447bc9b436 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -549,6 +549,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
{
MemoryContext col_context,
old_context;
+ bool build_ext_stats;
pgstat_progress_update_param(PROGRESS_ANALYZE_PHASE,
PROGRESS_ANALYZE_PHASE_COMPUTE_STATS);
@@ -613,12 +614,27 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
}
/*
+ * Should we build extended statistics for this relation?
+ *
+ * The extended statistics catalog does not include an inheritance
+ * flag, so we can't store statistics built both with and without
+ * data from child relations. We can store just one set of statistics
+ * per relation. For plain relations that's fine, but for inheritance
+ * trees we have to pick whether to store statistics for just the
+ * one relation or the whole tree. For plain inheritance we store
+ * the (!inh) version, mostly for backwards compatibility reasons.
+ * For partitioned tables that's pointless (the non-leaf tables are
+ * always empty), so we store stats representing the whole tree.
+ */
+ build_ext_stats = (onerel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE) ? inh : (!inh);
+
+ /*
* Build extended statistics (if there are any).
*
* For now we only build extended statistics on individual relations,
* not for relations representing inheritance trees.
*/
- if (!inh)
+ if (build_ext_stats)
BuildRelationExtStatistics(onerel, totalrows, numrows, rows,
attr_cnt, vacattrstats);
}