aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/trigger.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-07-06 14:23:09 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-07-06 14:23:09 -0400
commit64919aaab45076445051245c9bcd48dd84abebe7 (patch)
treecf176bd8605d075c61ce7884775e5a0ea60175ae /src/backend/commands/trigger.c
parentc7b7311f6177b90fe5033b8ed2c10dfcbb863eb6 (diff)
downloadpostgresql-64919aaab45076445051245c9bcd48dd84abebe7.tar.gz
postgresql-64919aaab45076445051245c9bcd48dd84abebe7.zip
Reduce the cost of planning deeply-nested views.
Joel Jacobson reported that deep nesting of trivial (flattenable) views results in O(N^3) growth of planning time for N-deep nesting. It turns out that a large chunk of this cost comes from copying around the "subquery" sub-tree of each view's RTE_SUBQUERY RTE. But once we have successfully flattened the subquery, we don't need that anymore, because the planner isn't going to do anything else interesting with that RTE. We already zap the subquery pointer during setrefs.c (cf. add_rte_to_flat_rtable), but it's useless baggage earlier than that too. Clearing the pointer as soon as pull_up_simple_subquery is done with the RTE reduces the cost from O(N^3) to O(N^2); which is still not great, but it's quite a lot better. Further improvements will require rethinking of the RTE data structure, which is being considered in another thread. Patch by me; thanks to Dean Rasheed for review. Discussion: https://postgr.es/m/797aff54-b49b-4914-9ff9-aa42564a4d7d@www.fastmail.com
Diffstat (limited to 'src/backend/commands/trigger.c')
0 files changed, 0 insertions, 0 deletions