Amit Kapila <amit.kapila16@gmail.com> writes:
> Tom, do you have input on this? Is it okay to backpatch this fix?
Well,
>> + * 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.
This comment seems fairly confused. I'd say something like
* Treat window functions as parallel-restricted because we aren't sure
* whether the input row ordering is fully deterministic, and the output
* of window functions might vary across workers if not. (In some cases,
* like where the window frame orders by a primary key, we could relax
* this restriction. But it doesn't currently seem worth expending extra
* effort to do so.)
>> 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?
I am *strongly* against this. It's unnecessary catalog churn that we
might need to undo someday, and it confuses a property of the window
function infrastructure with a property of individual window functions.
As a counterexample, if a window function were parallel-unsafe for
some reason, we'd surely need to honor that. More realistically,
someone might add a window function that actually needs to be
parallel-restricted for reasons of its own, but then there would be
no obvious distinction between such a function and one that you'd
hacked up to be marked parallel-restricted even though it's safe in
itself. If we then do make the sort of optimization suggested in the
comment, it's likely that someone would just s/r/s/g for all the window
functions and thereby break such a function. Better to retain the
correct per-function markings.
regards, tom lane