Re: Missing optimization when filters are applied after window functions - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Missing optimization when filters are applied after window functions
Date
Msg-id CAP7QgmnXVvz_w2WZi+qqd2vQGJHaokNs15x_u13zNjP5zfL5pQ@mail.gmail.com
Whole thread Raw
In response to Missing optimization when filters are applied after window functions  (Volker Grabsch <vog@notjusthosting.com>)
Responses Re: Missing optimization when filters are applied after window functions
List pgsql-hackers
On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch <vog@notjusthosting.com> wrote:
> I propose the following general optimization: If all window
> functions are partitioned by the same first field (here: id),
> then any filter on that field should be executed before
> WindowAgg. So a query like this:

I think that's possible.  Currently the planner doesn't think any
qualification from the upper query can be pushed down to a query that
has a window function.  It would be possible to let it push down if
the expression matches PARTITION BY expression.  However, the
challenge is that a query may have a number of window functions that
have different PARTITION BY expressions.  At the time of pushing down
in the planning, it is not obvious which window function comes first.
One idea is to restrict such optimization in only case of single
window function, and the other is to make it generalize and cover a
lot of cases.

That said, our planner on window functions has a lot of improvement to
be done.  Every kind of optimization I see is what I raised above;
they can be done easily by hacking in a small case, or they can be
done by generalizing for the most of cases.  My understanding is our
project tends to like the latter and it takes a little time but covers
more use cases.

Thanks,
-- 
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: read() returns ERANGE in Mac OS X
Next
From: Misa Simic
Date:
Subject: Re: 9.2 Beta: intersection of daterange