Andreas Kretschmer wrote:
> > they are being done over all rows. In this particular example you
> > happen to get the same result, but that's just because "avg(foo) over
> > partition by foo" is a dumb example --- it will necessarily just yield
> > identically foo. In more realistic computations
Tom Lane wrote:
> Andreas Kretschmer writes:
> > Tom Lane wrote:
> >> I see no bug here. Your second query asks for a much more complicated
> >> computation, it's not surprising it takes longer.
>
> > But sorry, I disagree. It is the same query with the same result. I can't
> > see
> > how t
Andreas Kretschmer writes:
> Tom Lane wrote:
>> I see no bug here. Your second query asks for a much more complicated
>> computation, it's not surprising it takes longer.
> But sorry, I disagree. It is the same query with the same result. I can't see
> how the queries should return different re
Tom Lane wrote:
> Andreas Kretschmer writes:
> > No question, this is a silly query, but the problem is the 2nd query: it
> > is obviously not possible for the planner to put the where-condition
> > into the subquery.
>
> Well, yeah: it might change the results of the window functions.
> I see
Andreas Kretschmer writes:
> No question, this is a silly query, but the problem is the 2nd query: it
> is obviously not possible for the planner to put the where-condition
> into the subquery.
Well, yeah: it might change the results of the window functions.
I see no bug here. Your second query
Hi,
version: 8.4.2
I have a table called values:
test=*# \d values
Table "public.values"
Column | Type | Modifiers
+-+---
id | integer |
value | real|
Indexes:
"idx_id" btree (id)
The table contains 10 random rows and is analysed.
And i hav
