Re: window function induces full table scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: window function induces full table scan
Date
Msg-id 4827.1388772253@sss.pgh.pa.us
Whole thread Raw
In response to Re: window function induces full table scan  (Thomas Mayer <thomas.mayer@student.kit.edu>)
Responses Re: window function induces full table scan
List pgsql-performance
Thomas Mayer <thomas.mayer@student.kit.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


pgsql-performance by date:

Previous
From: Thomas Mayer
Date:
Subject: Re: window function induces full table scan
Next
From: Thomas Mayer
Date:
Subject: Re: window function induces full table scan