On Wednesday 26 April 2006 10:30 am, you wrote: > Chris Kratz wrote: > > Hello all, > > > > I wanted to verify what we are seeing. > > > > Select a, aggregate(b) > > from c > > group by a > > order by a,b > > That's a rather odd query... Values in b aren't available to order by, > as they have been aggregated. There is no relation to the values in b > and the values in your result set. > > You could order by "column 2" if you want to order on the results on > your aggregate: > Select a, aggregate(b) > from c > group by a > order by a,2 Hello Alban, The point is that the aggregates we are working on in our application are order sensitive. One common example of order sensitive aggregates are the first and last aggregate functions found in some other databases. Both of which are very dependant on the order of the records going into the aggregate. Since you can't order the records before they hit the group by in postgres, the actual ordering of the records when they hit the aggregate function is indeterminate and so order sensitive aggregates really don't work. The best solution we have found so far is to feed the aggregating query with a subquery that orders on the appropriate columns. But even then, since the group by forces another sort, I'm not convinced that the ordering is still not indeterminate. I know you can use distinct on to get similar behavior for first and last, but that's not a general solution for aggregates that are order sensitive. I'm almost convinced that there isn't a way to do order sensitive aggregates in pg, but will have to pull the record set out and process it programmatically externally if the subquery trick doesn't work. -Chris -- Chris Kratz
