pgsql: Estimate cost of elided SubqueryScan, Append, MergeAppend nodes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Estimate cost of elided SubqueryScan, Append, MergeAppend nodes
Дата
Msg-id E1oDozT-000Hm7-Hp@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Estimate cost of elided SubqueryScan, Append, MergeAppend nodes better.

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

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e2f6c307c02924e6ee1667890b56280ab1960d2e

Modified Files
--------------
src/backend/optimizer/path/allpaths.c     | 33 ++++++++++++++++++
src/backend/optimizer/path/costsize.c     | 20 ++++++++++-
src/backend/optimizer/plan/setrefs.c      | 16 +++++----
src/backend/optimizer/prep/prepunion.c    | 27 ++++++++++++---
src/backend/optimizer/util/pathnode.c     | 56 ++++++++++++++++++++++++-------
src/include/optimizer/cost.h              |  3 +-
src/include/optimizer/pathnode.h          |  7 ++--
src/test/regress/expected/create_view.out | 16 ++++-----
src/test/regress/expected/join.out        |  8 ++---
9 files changed, 147 insertions(+), 39 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Default to hidden visibility for extension libraries where possi
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Convert planner's AggInfo and AggTransInfo structs to proper Nod