On Wed, May 16, 2012 at 09:25:13AM -0400, Tom Lane wrote:
Volker Grabsch v...@notjusthosting.com writes:
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
On Thu, May 17, 2012 at 7:26 AM, Volker Grabsch v...@notjusthosting.com wrote:
Hitoshi Harada schrieb:
On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch v...@notjusthosting.com
wrote:
I propose the following general optimization: If all window
functions are partitioned by the same first
Hitoshi Harada schrieb:
On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch v...@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
2012/5/17 Volker Grabsch v...@notjusthosting.com:
Also, is there any chance to include a (simple) attempt of
such an optimiztation into PostgreSQL-9.2 beta, or is this
only a possible topic for 9.3 and later?
For 9.2, you’re about 4 months late :-). The last commitfest was in Januari:
Dear PostgreSQL hackers,
[ please CC to me as I'm not subscribed to the list ]
I think there is a missing optimization when a filter is
applied after a window function, where the filtered field
is also used for partitioning.
Here a simplified example: Suppose we have a table
that stores 100.000
Volker Grabsch v...@notjusthosting.com writes:
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.
I'm not sure if that rule is correct in detail, but in
On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch v...@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
