On 2017-12-07 12:51:56 +1300, Thomas Munro wrote:
> 1.  Removing es_query_dsa and injecting the right context into the
> executor tree as discussed.
> 2.  Another idea mentioned by Robert in an off-list chat:  We could
> consolidate all DSM segments in a multi-gather plan into one.  See the
> nearby thread where someone had over a hundred Gather nodes and had to
> crank up max_connections to reserve enough DSM slots.  Of course,
> optimising for that case doesn't make too much sense (I suspect
> multi-gather plans will become less likely with Parallel Append and
> Parallel Hash in the picture anyway), but it would reduce a bunch of
> duplicated work we do when it happens as well as scarce slot
> consumption.  If we did that, then all of a sudden es_query_dsa would
> make sense again (ie it'd be whole-query scoped), and we could revert
> that hacky change.
> Or we could do both things anyway.

This is an open item for v11:

     Tidy up es_query_dsa and possibly ParallelWorkerContext?
        Original commit: e13029a5ce353574516c64fd1ec9c50201e705fd (principal 
author: Thomas Munro; owner: Robert Haas)
        Bug fix: fd7c0fa732d97a4b4ebb58730e6244ea30d0a618
        While the bug was fixed with something back-patchable, we should 
considering improving this situation. As discussed in the above-linked thread, 
options might include (1) getting rid of es_query_dsa entirely and injecting 
dependencies into nodes, (2) making all Gather nodes share the same DSM segment 
so there truly could be per-query DSA segment. 

Do we want to make any changes here for v11? If not, are we ok with just
closing the entry and waiting till it bugs anybody for some reason?


Andres Freund

Reply via email to