Re: window function induces full table scan

Thomas Mayer <thomas(dot)mayer(at)student(dot)kit(dot)edu> writes:
> ... "mark" ...: Do I understand you correctly, that you prefer doing the
> decision elsewhere and store the result (safe/unsafe) boolean value
> besides to the subquery output fields? For the push-down, a subquery
> output field must be available anyways.

See check_output_columns(). The infrastructure for deciding whether
a potentially-pushable qual refers to any unsafe subquery outputs already
exists; we just need to extend it to consider outputs unsafe if they
don't appear in all PARTITION BY lists.

>> Offhand I think the details of testing whether a given output column
>> appears in a given partition clause are identical to testing whether
>> it appears in the distinctClause. So you'd just be mechanizing running
>> through the windowClause list to verify whether this holds for all
>> the WINDOW clauses.

> When a field is element of all PARTITION BY clauses of all window
> functions, it does not mean that this field is distinct.

No, I didn't say that. What I meant was that (a) the is_pushdown_safe
logic can treat non-partitioning subquery outputs much like non-DISTINCT
outputs, and (b) the parsetree representation of PARTITION BY is enough
like DISTINCT ON that the same kind of test (viz, a targetIsInSortList
call) will serve.

I think you need to read the code around subquery_is_pushdown_safe and
qual_is_pushdown_safe some more.

regards, tom lane