On Wed, Nov 29, 2017 at 7:30 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > While reviewing commit c6755e23 I realised that es_query_dsa is > broken. It might have made some kind of sense as a name and a concept > in an earlier version of the proposal to add a DSA area for parallel > query's use, when the DSA area was going to be independent of parallel > query DSM segments and could have been used for the whole query. But > as it stands, each Gather [Merge] node has its own DSA area in its own > DSM segment, and that needs to be the one available to the nodes of > the child plan when executed in the leader process and it needs to be > not available to any other nodes in the tree. It's OK for the workers > to have just one es_query_dsa set up at the beginning and used for the > whole lifetime of the executor, but it's not OK for the leader to > install it and forget about it as it does now.
Ugh. > Better ideas? How about this: 1. Remove es_query_dsa altogether. 2. Add a dsa_area * to ExecParallelInitializeDSMContext. 3. In ExecParallelInitializeDSM, pass the dsa_area * as a separate to the per-node-type function. 4. If the per-node-type function cares about the dsa_area *, it is responsible for saving a pointer to it in the PlanState node. 5. Also pass it down via the ParallelWorkerContext. In v10 we might need to go with a solution like what you've sketched here, because Tom will complain about breaking binary compatibility with EState (and maybe other PlanState nodes) in a released branch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
