If I do 4 selects in order 1, 2, 3, 4, using UNION ALL, the results come back 1, 4, 3, 2. Why? I can use ORDER BY to rearrange the order, but why is it in this seemingly "out of order" order by default? Use this table:
Use this SELECT block:
Results:
asked 07 Dec '10, 20:05 Siger Matt Nica _SAP |
Your query won't run as submitted. Remove the semi-colon after the third select statement. You can't depend on the results of any query unless you tell it how you want the result set to be sorted. To order a set of union-ed selects, add ORDER BY column number(s) at the end. Your new query would be:
answered 07 Dec '10, 20:58 SethKrieger Volker Barth Fixed the semi-colon. I realize that you can use order by to force order on the results. I just wondered why without me forcing them to be ordered they would not appear in the same order as the select statements. @Siger: Well, that's the effect of query optimization. The engine is not at all bound to execute the different branches in the order you or me would expect:) Comment Text Removed
Comment Text Removed
1
@SethKrieger: It's funny, folks have been giving the "you can't depend" answer for years, and it's finally coming true... the query engine is finally using the Infinite Improbability Drive even on cases like this :) 1
@Breck, so you think Sybase will skip the unlucky version 13 and rename the product "Heart of Gold?" 1
@Volker: I suppose before this discussion I would have asserted that the execution of the branches could be in any order for the purpose of the optimization, but that the returning of the results would be independent of the execution and would be in the order of the statements, unless I used ORDER BY. Clearly I would have been wrong. Execution and returning results seem to be the same thing. |
Unlike some other languages - e.g. C/C++ - the SQL language does not guarentee the order of operations taken to execute a statement. As such, the SQL optimizer and execution engine is allowed to perform the operations in any order that it sees fit, presumably in an attempt to execute the statement as quickly as possible. You did not specify the version (and build number) that you are using so it is difficult to determine why you got the output that you did - possibly due to a parallel execution plan or perhaps an artifact in the way the statement is parsed - but as Seth has mentioned, the only way that you can guarantee the ordering of the output is to use an ORDER BY clause. answered 07 Dec '10, 21:57 Mark Culp |
Version 12.0 EBF 2601