From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: Thomas Mayer <thomas.mayer@student.kit.edu>,
 pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: window function induces full table scan
In-reply-to: 
 <CAMkU=1zcZH+7_kzAS_jWR-soz7YWUeu6nYeTtAMhiDt6BQKTpw@mail.gmail.com>
References: <52C5DAD1.20109@student.kit.edu> <17191.1388699570@sss.pgh.pa.us>
 <CAMkU=1zcZH+7_kzAS_jWR-soz7YWUeu6nYeTtAMhiDt6BQKTpw@mail.gmail.com>
Comments: In-reply-to Jeff Janes <jeff.janes@gmail.com>
 message dated "Thu, 02 Jan 2014 14:26:31 -0800"
Date: Thu, 02 Jan 2014 17:43:12 -0500
Message-ID: <18380.1388702592@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Jeff Janes <jeff.janes@gmail.com> writes:
> On Thu, Jan 2, 2014 at 1:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's possible that in the specific case you exhibit here, pushing down
>> the clause wouldn't result in changes in the window function's output for
>> the selected rows, but the optimizer doesn't have enough knowledge about
>> window functions to determine that.

> A restriction in the WHERE clause which corresponds to the PARTITION BY
> should be pushable, no?  I think it doesn't need to understand the internal
> semantics of the window function itself, just of the PARTITION BY, which
> should be doable, at least in principle.

If the restriction clause must give the same answer for any two rows of
the same partition, then yeah, we could in principle push it down without
knowing anything about the specific window function.  It'd be a less than
trivial test to make, I think.  In any case, it's not a "bug" that the
optimizer doesn't do this currently.

			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