Am 03.01.2014 19:04, schrieb Tom Lane:
I think you need to read the code around subquery_is_pushdown_safe and
qual_is_pushdown_safe some more.
regards, tom lane
.
In general, I'd need to go throught the pg source code which will take
some time. For instance, I wanted
Thomas Mayer writes:
> ... "mark" ...: Do I understand you correctly, that you prefer doing the
> decision elsewhere and store the result (safe/unsafe) boolean value
> besides to the subquery output fields? For the push-down, a subquery
> output field must be available anyways.
See check_outpu
Am 03.01.2014 15:54, schrieb Tom Lane:
Thomas Mayer 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 PA
Thomas Mayer 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 func
I have just cloned the postgresql git repository and checked out the
REL9_3_2 tagged version to have a look at the
src/backend/optimizer/path/allpaths.c file.
As Tom already mentioned, quals are currently not pushed down when
subqueries with window functions occur:
There is a function subque
Just to track it down: The limitation can also be reproduced without
using views. Using views is just a use case where the suggested
optimization is actually needed.
Plus, when I remove the condition "WHERE datepos = 1", the same
behaviour still occurs. Here, I wanted to see if postgresql is
I wrote:
> 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.
On reflection, really this con
Am 02.01.2014 23:43, schrieb Tom Lane:
Jeff Janes writes:
On Thu, Jan 2, 2014 at 1:52 PM, Tom Lane 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 does
You understood me correctly, Tom.
As you mention, the result would be correct in my case:
- The window function is performing a "PARTITION BY user_id".
- user_id is used for the WHERE condition.
I agree, that in general (PARTITION BY and WHERE don't use the same set
of attributes), incorrect re
Jeff Janes writes:
> On Thu, Jan 2, 2014 at 1:52 PM, Tom Lane 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
>
On Thu, Jan 2, 2014 at 1:52 PM, Tom Lane wrote:
> Thomas Mayer writes:
> > When querying a view with a WHERE condition, postgresql normally is able
> > to perform an index scan which reduces time for evaluation dramatically.
>
> > However, if a window function is evaluated in the view, postgresq
Thomas Mayer writes:
> When querying a view with a WHERE condition, postgresql normally is able
> to perform an index scan which reduces time for evaluation dramatically.
> However, if a window function is evaluated in the view, postgresql is
> evaluating the window function before the WHERE co
When querying a view with a WHERE condition, postgresql normally is able
to perform an index scan which reduces time for evaluation dramatically.
However, if a window function is evaluated in the view, postgresql is
evaluating the window function before the WHERE condition is applied.
This ind
13 matches
Mail list logo
