Commit Graph

8 Commits

Author SHA1 Message Date
drh
4fe425ad79 "make test" now passing.
FossilOrigin-Name: addd7f466d6ff55f82d907286650c26b06e9397b
2013-06-12 17:08:06 +00:00
drh
aec93a1f2d Test case updates.
FossilOrigin-Name: 0360fec7c093870269211447e9642b5ee34ff778
2013-06-04 15:31:16 +00:00
drh
782d68a4cd Try to take into account the cost of inner loops when selecting which table
of a join to use for the outer loop.

FossilOrigin-Name: 942556342a332b04a11169bb04f387d741ef9488
2012-11-09 17:59:26 +00:00
drh
2fad815c52 All test cases (veryquick.tcl and min.rc) pass. A few branch operations in
ORDER BY optimization logic are untested by min.rc.

FossilOrigin-Name: 8314fd6078a3a71aea9d6386ff277cfeb592b4ba
2012-10-08 21:01:15 +00:00
drh
afcd522af8 More lenient handling of ORDER BY optimization in joins with mixed ASC/DESC.
This is a better and less restrictive fix for the problem addressed by
the previous check-in.

FossilOrigin-Name: abcf6a5d054559ee5a093ba39180c47b4958d9cd
2012-10-02 15:19:19 +00:00
drh
178eb61c6b Only continue an ORDER BY optimization into inner loops if the equality
constraints on the inner loop match terms of an outer ordered index that
are actually used by the ORDER BY clause.

FossilOrigin-Name: b0e7b4df6c2a8c479f8d210bde50c737eaa248f0
2012-10-02 14:11:29 +00:00
drh
5343b2d4a8 More test cases an bug fixes for the ORDER BY optimization of joins. All
veryquick tests now pass.

FossilOrigin-Name: 0d573320057b0903a5589cabfb1b1ece1c57958e
2012-09-27 19:53:38 +00:00
drh
6b10a6a7ed Test cases and bug fixes applied to the ORDER BY optimization for joins.
Some test cases fail, but except for the new orderby1.test failures, all
failures appear to be issues with the tests, not with the core code.

FossilOrigin-Name: 75cda864ededb6dc0f84bd52ed3311753a58e351
2012-09-27 17:31:32 +00:00