Prev: Standalone backends run StartupXLOG in an incorrect environment
Next: [HACKERS] Opa
From: Tom Lane on 23 Mar 2010 11:23
Hitoshi Harada <umi.tanuki(a)gmail.com> writes:
> I believe the changes will probably not be 2-3 lines (ie. a member
> added to Query structure, etc) if I try it. But the optimizer part is
> too complicated to me so that I am not sure, either. My idea above is
> that the similar mechanism you see in GROUP BY optimization will help
> you and the issue is not so particular about window functions.

The real question is what benefit you expect to get. If the filter
condition can't be pushed below the window functions (which AFAICS it
can't without changing the results) then there is really nothing to be
gained compared to leaving it in the outer query level.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Daniel Farina on 23 Mar 2010 12:46
On Tue, Mar 23, 2010 at 8:23 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> The real question is what benefit you expect to get.  If the filter
> condition can't be pushed below the window functions (which AFAICS

Even on the partition key?

Right now if you define a view with a windowing + PARTITION BY clause
in it and people write a lot of queries to interrogate one partition
or the other, you end up computing results for the entire relation,
and then filtering all but one partition out, in my understanding.

Since it seems on the surface there is no context sensitivity(?)
between partitions in this kind of a case it would seem a qual
pushdown on the partition key would help rather intensely.

fdr

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: Standalone backends run StartupXLOG in an incorrect environment
Next: [HACKERS] Opa