Re: executor relation handling
David Rowley <david.rowley@2ndquadrant.com>
On 8 October 2018 at 13:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The idea I had in mind was to allow hard pruning of any leaf that's > been excluded *at plan time* based on partition constraints seen in > its parent rel(s). That should be safe enough as long as we take > locks on all the non-leaf rels --- then we'd know about any change > in the constraint situation. > > Rather than coping with renumbering the RTEs, it might be easiest > to invent an "RTE_DUMMY" RTE type that a hard-pruned RTE could be > changed to. The problem with that is that, if we get [1] done in PG12, then the RTE_DUMMYs would not exist, as we'd only have RTEs in the range table for partitions that survived plan-time pruning. It also leaves a problem to solve in the unneeded locks being taken on partitions for PREPAREd queries using run-time pruning. [1] https://commitfest.postgresql.org/20/1778/ -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Avoid O(N^2) cost in ExecFindRowMark().
- f9eb7c14b08d 12.0 landed
-
Remove some unnecessary fields from Plan trees.
- 52ed730d511b 12.0 landed
-
Restore sane locking behavior during parallel query.
- 29ef2b310da9 12.0 landed
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 landed
-
In the executor, use an array of pointers to access the rangetable.
- d73f4c74dd34 12.0 landed
-
Centralize executor's opening/closing of Relations for rangetable entries.
- 9ddef36278a9 12.0 landed
-
Change executor to just Assert that table locks were already obtained.
- 9a3cebeaa7fd 12.0 landed
-
Change rewriter/planner/executor/plancache to depend on RTE rellockmode.
- 6e35939febf8 12.0 landed
-
Add assertions that we hold some relevant lock during relation open.
- b04aeb0a053e 12.0 landed
-
Create an RTE field to record the query's lock mode for each relation.
- fdba460a26af 12.0 landed