From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: es_query_dsa is broken |
Date: | 2017-11-29 15:01:37 |
Message-ID: | CA+TgmoZe-jMNySJGNP+vBZZNDHjty6HZ=OaAJbd9z-CH7hrWwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 29, 2017 at 7:30 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-11-29 15:03:07 | Re: [HACKERS] static assertions in C++ |
Previous Message | Victor Drobny | 2017-11-29 14:57:33 | Re: new function for tsquery creartion |