]> granicus.if.org Git - postgresql/commit
Eliminate a lot of list-management overhead within join_search_one_level
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 28 Nov 2009 00:46:19 +0000 (00:46 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 28 Nov 2009 00:46:19 +0000 (00:46 +0000)
commit1a95f12702b4e535b5e26ed9c3fcd0b2a1b1a20f
treec56c54fce5968c874b21fb902c1090b486da4719
parentfe83b975b2bdfa9b553872aa9a5dc959ca89a51f
Eliminate a lot of list-management overhead within join_search_one_level
by adding a requirement that build_join_rel add new join RelOptInfos to the
appropriate list immediately at creation.  Per report from Robert Haas,
the list_concat_unique_ptr() calls that this change eliminates were taking
the lion's share of the runtime in larger join problems.  This doesn't do
anything to fix the fundamental combinatorial explosion in large join
problems, but it should push out the threshold of pain a bit further.

Note: because this changes the order in which joinrel lists are built,
it might result in changes in selected plans in cases where different
alternatives have exactly the same costs.  There is one example in the
regression tests.
src/backend/nodes/outfuncs.c
src/backend/optimizer/geqo/geqo_eval.c
src/backend/optimizer/path/allpaths.c
src/backend/optimizer/path/joinrels.c
src/backend/optimizer/plan/planmain.c
src/backend/optimizer/util/relnode.c
src/include/nodes/relation.h
src/include/optimizer/paths.h
src/test/regress/expected/join.out