database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-11 10:01:57 +03:00
Code Activity

Estimate cost of elided SubqueryScan, Append, MergeAppend nodes better.

Browse Source 
setrefs.c contains logic to discard no-op SubqueryScan nodes, that is,
ones that have no qual to check and copy the input targetlist unchanged.
(Formally it's not very nice to be applying such optimizations so late
in the planner, but there are practical reasons for it; mostly that we
can't unify relids between the subquery and the parent query until we
flatten the rangetable during setrefs.c.)  This behavior falsifies our
previous cost estimates, since we would've charged cpu_tuple_cost per
row just to pass data through the node.  Most of the time that's little
enough to not matter, but there are cases where this effect visibly
changes the plan compared to what you would've gotten with no
sub-select.

To improve the situation, make the callers of cost_subqueryscan tell
it whether they think the targetlist is trivial.  cost_subqueryscan
already has the qual list, so it can check the other half of the
condition easily.  It could make its own determination of tlist
triviality too, but doing so would be repetitive (for callers that
may call it several times) or unnecessarily expensive (for callers
that can determine this more cheaply than a general test would do).

This isn't a 100% solution, because createplan.c also does things
that can falsify any earlier estimate of whether the tlist is
trivial.  However, it fixes nearly all cases in practice, if results
for the regression tests are anything to go by.

setrefs.c also contains logic to discard no-op Append and MergeAppend
nodes.  We did have knowledge of that behavior at costing time, but
somebody failed to update it when a check on parallel-awareness was
added to the setrefs.c logic.  Fix that while we're here.

These changes result in two minor changes in query plans shown in
our regression tests.  Neither is relevant to the purposes of its
test case AFAICT.

Patch by me; thanks to Richard Guo for review.

Discussion: https://postgr.es/m/2581077.1651703520@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2022-07-19 11:18:19 -04:00
parent 1679d57a55
commit e2f6c307c0
9 changed files with 147 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/backend/optimizer/plan/setrefs.c
View File

@ -1636,9 +1636,10 @@ set_append_references(PlannerInfo *root,
/*
* See if it's safe to get rid of the Append entirely. For this to be
* safe, there must be only one child plan and that child plan's parallel
* awareness must match that of the Append's. The reason for the latter
* is that if the Append is parallel aware and the child is not, then the
* calling plan may execute the non-parallel aware child multiple times.
* awareness must match the Append's. The reason for the latter is that
* if the Append is parallel aware and the child is not, then the calling
* plan may execute the non-parallel aware child multiple times. (If you
* change these rules, update create_append_path to match.)
*/
if (list_length(aplan->appendplans) == 1)
{
@ -1710,10 +1711,11 @@ set_mergeappend_references(PlannerInfo *root,
/*
* See if it's safe to get rid of the MergeAppend entirely. For this to
* be safe, there must be only one child plan and that child plan's
* parallel awareness must match that of the MergeAppend's. The reason
* for the latter is that if the MergeAppend is parallel aware and the
* child is not then the calling plan may execute the non-parallel aware
* child multiple times.
* parallel awareness must match the MergeAppend's. The reason for the
* latter is that if the MergeAppend is parallel aware and the child is
* not, then the calling plan may execute the non-parallel aware child
* multiple times. (If you change these rules, update
* create_merge_append_path to match.)
*/
if (list_length(mplan->mergeplans) == 1)
{