aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/explain.c
diff options
context:
space:
mode:
authorRichard Guo <rguo@postgresql.org>2025-02-17 11:13:15 +0900
committerRichard Guo <rguo@postgresql.org>2025-02-17 11:13:15 +0900
commitfbc0fe9a2efeb6172f93ad74a9656fdac5de2507 (patch)
treea6d89c218267c240a2af7682ccb30c1b5b56d154 /src/backend/commands/explain.c
parenta7f95859ef7763ffb7f87894553ab25f5268f33c (diff)
downloadpostgresql-fbc0fe9a2efeb6172f93ad74a9656fdac5de2507.tar.gz
postgresql-fbc0fe9a2efeb6172f93ad74a9656fdac5de2507.zip
Adjust tuples estimate for appendrels
In set_append_rel_size(), we currently set rel->tuples to rel->rows for an appendrel. Generally, rel->tuples is the raw number of tuples in the relation and rel->rows is the estimated number of tuples after the relation's restriction clauses have been applied. Although an appendrel itself doesn't directly enforce any quals today, its child relations may. Therefore, setting rel->tuples equal to rel->rows for an appendrel isn't always appropriate. Doing so can lead to issues in cost estimates in some cases. For instance, when estimating the number of distinct values from an appendrel, we would not be able to adjust the estimate based on the restriction selectivity. This patch addresses this by setting an appendrel's tuples to the total number of tuples accumulated from each live child, which better aligns with reality. This is arguably a bug, but nobody has complained about that until now, so no back-patch. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: Alena Rybakina <a.rybakina@postgrespro.ru> Discussion: https://postgr.es/m/CAMbWs4_TG_+kVn6fjG-5GYzzukrNK57=g9eUo4gsrUG26OFawg@mail.gmail.com
Diffstat (limited to 'src/backend/commands/explain.c')
0 files changed, 0 insertions, 0 deletions