Re: window function induces full table scan
От | Tom Lane |
---|---|
Тема | Re: window function induces full table scan |
Дата | |
Msg-id | 4827.1388772253@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: window function induces full table scan (Thomas Mayer <thomas.mayer@student.kit.edu>) |
Ответы |
Re: window function induces full table scan
|
Список | 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 по дате отправления: