On Fri, Sep 25, 2015 at 12:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> In the latest patch (parallel_seqscan_partialseqscan_v18.patch) posted by
> me yesterday, this was fixed. Am I missing something or by any chance
> you are referring to wrong version of patch
You're right, I'm wrong. Sorry.
> Yes, the patch needs more work in terms of dealing with parallel-restricted
> expressions/functions. One idea which I have explored previously is
> push down only safe clauses to workers (via partialseqscan node) and
> execute restricted clauses in master (via Funnel node). My analysis
> is as follows:
>
> Usage of restricted functions in quals-
> During create_plan() phase, separate out the quals that needs to be
> executed at funnel node versus quals that needs to be executed on
> partial seq scan node (do something similar to what is done in
> create_indexscan_plan for index and non-index quals).
>
> Basically PartialSeqScan node can contain two different list of quals,
> one for non-restrictive quals and other for restrictive quals and then
> Funnel node can retrieve restrictive quals from partialseqscan node,
> assuming partialseqscan node is its left child.
>
> Now, I think the above can only be possible under the assumption that
> partialseqscan node is always a left child of funnel node, however that is
> not true because a gating node (Result node) can be added between the
> two and tomorrow there could be more cases when other nodes will be
> added between the two, if we consider the case of aggregation, the
> situation will be more complex as before partial aggregation, all the
> quals should be executed.
What's the situation where the gating Result node sneaks in there?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
