Nab some low-hanging fruit: replace the planner's base_rel_list and
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 6 Jun 2005 04:13:36 +0000 (04:13 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 6 Jun 2005 04:13:36 +0000 (04:13 +0000)
commit9a586fe0c5a9228cc60428207a3fb64fb392b848
tree41b2a2cdcddc6f5b627e1f6817e91e2ba0b859e8
parent9ab4d98168407c3436d3f0e02d32720b0d9075a0
Nab some low-hanging fruit: replace the planner's base_rel_list and
other_rel_list with a single array indexed by rangetable index.
This reduces find_base_rel from O(N) to O(1) without any real penalty.
While find_base_rel isn't one of the major bottlenecks in any profile
I've seen so far, it was starting to creep up on the radar screen
for complex queries --- so might as well fix it.
src/backend/nodes/outfuncs.c
src/backend/optimizer/path/allpaths.c
src/backend/optimizer/plan/planmain.c
src/backend/optimizer/util/relnode.c
src/include/nodes/relation.h