Re: Missing optimization when filters are applied after window functions

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Volker Grabsch <vog(at)notjusthosting(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Missing optimization when filters are applied after window functions
Date: 2012-05-16 14:23:39
Message-ID: CAP7QgmnXVvz_w2WZi+qqd2vQGJHaokNs15x_u13zNjP5zfL5pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch <vog(at)notjusthosting(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-05-16 15:36:26 Re: Strange issues with 9.2 pg_basebackup & replication
Previous Message Andrew Dunstan 2012-05-16 14:23:07 Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more