diff options
author | drh <drh@noemail.net> | 2010-04-26 19:17:26 +0000 |
---|---|---|
committer | drh <drh@noemail.net> | 2010-04-26 19:17:26 +0000 |
commit | 8c6f666b26cd8244da3d7fb6da478b43105bc679 (patch) | |
tree | e9ba3b47bce4b9e584f97c3f785619c8477e6ba8 /src/select.c | |
parent | 93791ea0bac51d58675a54621e3fd7a1cce75d36 (diff) | |
download | sqlite-8c6f666b26cd8244da3d7fb6da478b43105bc679.tar.gz sqlite-8c6f666b26cd8244da3d7fb6da478b43105bc679.zip |
Optimization: Convert an ORDER BY clause into a no-op if the query also
contains a GROUP BY clause that will force the same output order.
FossilOrigin-Name: ca9d86baf70f210d331ce93102177c8005c494cb
Diffstat (limited to 'src/select.c')
-rw-r--r-- | src/select.c | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/src/select.c b/src/select.c index 47e409ffc..9a016039a 100644 --- a/src/select.c +++ b/src/select.c @@ -3718,6 +3718,18 @@ int sqlite3Select( isDistinct = 0; } + /* If there is both a GROUP BY and an ORDER BY clause and they are + ** identical, then disable the ORDER BY clause since the GROUP BY + ** will cause elements to come out in the correct order. This is + ** an optimization - the correct answer should result regardless. + ** Use the SQLITE_GroupByOrder flag with SQLITE_TESTCTRL_OPTIMIZER + ** to disable this optimization for testing purposes. + */ + if( sqlite3ExprListCompare(p->pGroupBy, pOrderBy)==0 + && (db->flags & SQLITE_GroupByOrder)==0 ){ + pOrderBy = 0; + } + /* If there is an ORDER BY clause, then this sorting ** index might end up being unused if the data can be ** extracted in pre-sorted order. If that is the case, then the |