On Wed, Nov 29, 2017 at 7:30 AM, Thomas Munro
<thomas.munro@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
