Re: executor relation handling
Robert Haas <robertmhaas@gmail.com>
On Sat, Oct 6, 2018 at 2:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > The reasons why we need locks on tables not physically accessed by the > query are (a) to ensure that we've blocked, or received sinval messages > for, any DDL related to views or partition parent tables, in case that > would invalidate the plan; (b) to allow firing triggers safely, in > the case of partition parent tables. Neither of these issues apply to > a parallel worker -- the plan is already frozen before it can ever > start, and it isn't going to be firing any triggers either. That last part could *easily* change in a future release. We've already started to allow CTAS with parallel query, and there have already been multiple people wanting to allow more. It would be a shame if we threw up additional obstacles in the way of that... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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