On Wed, Jul 15, 2020 at 6:14 PM Zhenghua Lyu <z...@vmware.com> wrote: > > > The first plan: > > Finalize Aggregate > -> Gather > Workers Planned: 2 > -> Partial Aggregate > -> Nested Loop > Join Filter: (t3.c1 = t4.c1) > -> Parallel Seq Scan on t3 > Filter: (c1 ~~ '%sss'::text) > -> Seq Scan on t4 > Filter: (timeofday() = c1) > > The join's left tree is parallel scan and the right tree is seq scan. > This algorithm is correct using the distribute distributive law of > distributed join: > A = [A1 A2 A3...An], B then A join B = gather( (A1 join B) (A2 join B) > ... (An join B) ) > > The correctness of the above law should have a pre-assumption: > The data set of B is the same in each join: (A1 join B) (A2 join B) ... > (An join B) > > But things get complicated when volatile functions come in. Timeofday is just > an example to show the idea. The core is volatile functions can return > different > results on successive calls with the same arguments. Thus the following piece, > the right tree of the join > -> Seq Scan on t4 > Filter: (timeofday() = c1) > can not be considered consistent everywhere in the scan workers. >
But this won't be consistent even for non-parallel plans. I mean to say for each loop of join the "Seq Scan on t4" would give different results. Currently, we don't consider volatile functions as parallel-safe by default. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
