Philip Warner <pjw@rhyme.com.au> writes:
>>> SQL in general doesn't believe that tuple ordering has any semantic
>>> significance --- you can ask for ORDER BY, but that's only honored
>>> at the end stage of SELECT result delivery, not necessarily anywhere
>>> in the bowels of a query.
> Out of curiosity, does the SQL spec give any rules or guidelines about when
> aggregates should be applied to resultant rows? Or is it one of the
> implementation-dependant things?
Well, SQL's conceptual model is perfectly clear about the processing
work flow of a SELECT: after you've constructed the tuple set (which
might involve joining multiple relations), you apply the WHERE condition
to filter out uninteresting tuples. Then you apply GROUP BY (if given)
to divvy the tuples into groups. Then you apply HAVING to eliminate
uninteresting groups. Then you apply aggregate functions (if any) to
individual groups, or to the whole filtered result set if no groups.
Finally you apply ORDER BY to whatever's left.
Note that at no point except the final output is there any notion
of the tuples being generated or processed in a particular order.
Given appropriate hardware, much of this could be done in parallel.
Parallel or not, an implementation is free to choose the processing
order for its convenience.
regards, tom lane