From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Mayer <thomas.mayer@student.kit.edu>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: window function induces full table scan
Date: Fri, 03 Jan 2014 09:54:25 -0500
Message-ID: <9269.1388760865@sss.pgh.pa.us> (raw)
In-Reply-To: <52C63E8B.2040806@student.kit.edu>
References: <52C5DAD1.20109@student.kit.edu>
<17191.1388699570@sss.pgh.pa.us>
<CAMkU=1zcZH+7_kzAS_jWR-soz7YWUeu6nYeTtAMhiDt6BQKTpw@mail.gmail.com>
<18380.1388702592@sss.pgh.pa.us>
<20167.1388706955@sss.pgh.pa.us>
<52C63E8B.2040806@student.kit.edu>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
Thomas Mayer <thomas.mayer@student.kit.edu> writes:
> To implement the optimization, subquery_is_pushdown_safe() needs to
> return true if pushing down the quals to a subquery which has window
> functions is in fact safe ("quals that only reference subquery
> outputs that are listed in the PARTITION clauses of all window functions
> in the subquery").
I'd just remove that check.
> Plus, there is a function qual_is_pushdown_safe(...) which contains an
> assertion, which might possibly become obsolete:
No, that should stay. There are no window functions in the upper query's
WHERE, there will be none pushed into the lower's WHERE, and that's as it
must be.
> Tom, do you think that these two changes could be sufficient?
Certainly not. What you'd need to do is include the
is-it-listed-in-all-PARTITION-clauses consideration in the code that marks
"unsafe" subquery output columns. And update all the relevant comments.
And maybe add a couple of regression test cases.
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.
Note that if you just look at the windowClause list, then you might
be filtering by named window definitions that appeared in the WINDOW
clause but were never actually referenced by any window function.
I don't have a problem with blowing off the optimization in such cases.
I don't think it's appropriate to expend the cycles that would be needed
to discover whether they're all referenced at this point. (If anyone ever
complains, it'd be much cheaper to modify the parser to get rid of
unreferenced window definitions.)
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.mayer@student.kit.edu, jeff.janes@gmail.com
Subject: Re: window function induces full table scan
In-Reply-To: <9269.1388760865@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox