On Tue, Aug 21, 2018 at 8:44 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Aug 20, 2018 at 6:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Sounds to me like you're using the wrong approach. I would just consider
> > any Agg or WindowFunc node as parallel-restricted regardless of the
> > function it references.
> >
>
> I have below change in the patch which I think is on the lines what
> you are describing, do you have something different in mind?
>
> @@ -1197,6 +1197,19 @@ max_parallel_hazard_walker(Node *node,
> max_parallel_hazard_context *context)
> }
>
> /*
> + * Treat window functions as parallel-restricted as the row ordering
> + * induced by them is non-deterministic. We can relax this condition for
> + * cases where the row ordering can be deterministic like when there is
> + * an ORDER BY on the primary key, but those cases don't seem to be
> + * interesting enough to have additional checks.
> + */
> + if (IsA(node, WindowFunc))
> + {
> + if (max_parallel_hazard_test(PROPARALLEL_RESTRICTED, context))
> + return true;
> + }
>
> In addition to the above, I have marked all built-in window functions
> as parallel-restricted. I think even if we don't do that something
> like above check should be sufficient, but OTOH, I don't see any
> reason to keep the marking of such functions as parallel-safe. Is
> there a reason, why we shouldn't mark them as parallel-restricted?
>
Tom, do you have input on this? Is it okay to backpatch this fix?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com