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
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 i
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
tepos
FROM checkin_node
) AS tmp_last_position
WHERE user_id = 43; -- takes 6574 ms
Best regards,
Thomas
Am 03.01.2014 00:12, schrieb Thomas Mayer:
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 i
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
1.2014 22:52, schrieb Tom Lane:
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
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
