On Fri, Sep 25, 2015 at 12:55 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers