On 16 September 2017 at 11:45, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Sep 14, 2017 at 8:30 PM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 11 September 2017 at 18:55, Amit Kapila <amit.kapil...@gmail.com> wrote: >>>> >>> >>> How? See, if you have four partial subpaths and two non-partial >>> subpaths, then for parallel-aware append it considers all six paths in >>> parallel path whereas for non-parallel-aware append it will consider >>> just four paths and that too with sub-optimal strategy. Can you >>> please try to give me some example so that it will be clear. >> >> Suppose 4 appendrel children have costs for their cheapest partial (p) >> and non-partial paths (np) as shown below : >> >> p1=5000 np1=100 >> p2=200 np2=1000 >> p3=80 np3=2000 >> p4=3000 np4=50 >> >> Here, following two Append paths will be generated : >> >> 1. a parallel-aware Append path with subpaths : >> np1, p2, p3, np4 >> >> 2. Partial (i.e. non-parallel-aware) Append path with all partial subpaths: >> p1,p2,p3,p4 >> >> Now, one thing we can do above is : Make the path#2 parallel-aware as >> well; so both Append paths would be parallel-aware. >> > > Yes, we can do that and that is what I think is probably better. So, > the question remains that in which case non-parallel-aware partial > append will be required? Basically, it is not clear to me why after > having parallel-aware partial append we need non-parallel-aware > version? Are you keeping it for the sake of backward-compatibility or > something like for cases if someone has disabled parallel append with > the help of new guc in this patch?
Yes one case is the enable_parallelappend GUC case. If a user disables it, we do want to add the usual non-parallel-aware append partial path. About backward compatibility, the concern we discussed in [1] was that we better continue to have the usual non-parallel-aware partial Append path, plus we should have an additional parallel-aware Append path containing mix of partial and non-partial subpaths. But thinking again on the example above, I think Amit, I tend to agree that we don't have to worry about the existing behaviour, and so we can make the path#2 parallel-aware as well. Robert, can you please suggest what is your opinion on the paths that are chosen in the above example ? [1] https://www.postgresql.org/message-id/CA%2BTgmoaLRtaWdJVHfhHej2s7w1spbr6gZiZXJrM5bsz1KQ54Rw%40mail.gmail.com > -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers