On Wed, Jul 15, 2020 at 6:14 PM Zhenghua Lyu <zlyu@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:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.enterprisedb.com%2F&data=02%7C01%7Czlyu%40vmware.com%7C825aa0c2259c4da0112008d8293dcd1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637304692698598521&sdata=LWZnJ43KQML3EBwB2DoPGE0KHA2t6A3%2FIS9KSLx%2Bcn4%3D&reserved=0
