On 4/6/19, Jinho Jung <[email protected]> wrote: > > +----------------------+--------+ > | Query | Time | > +----------------------+--------+ > | 10002.sql (v3.23) | 789 | > | 10002.sql (v3.27.2) | 1270 | > +----------------------+--------+ > | 10052.sql (v3.23) | 3094 | > | 10052.sql (v3.27.2) | 4478 | > +----------------------+--------+ > > 1) 10002.sql shows 60% performance regression > - bisect fossil commit: > === 2018-12-31 === > [9fb646f29c] *MERGE* Merge enhancements and bug fixes from trunk. (user: > drh tags: reuse- > subqueries)
I confirm that your test case is slightly slower on v3.28.0 compared to v3.23.0. But when I do the bisect, I land on a very different (and more plausible) check-in: https://sqlite.org/src/info/e130319317e76119 Here is the result of my bisect: https://sqlite.org/src/timeline?bid=y736b53f57fn03f2e78899y8eb62fd5fan9cf8ebd141n0888fc2e88y4cdcda408ay6821c61f1dy4678cb1044n0465d2fc0dn5c188361a9nb57c545a38ne130319317yf856676c84 > > 2) 10052.sql shows 40% performance regression > - bisect fossil commit: > === 2018-12-24 === > [7153552bac] Improvements to EXPLAIN QUERY PLAN formatting. The > MULTI-INDEX OR now > shows a separate "INDEX" subtree for each index. SCALAR SUBQUERY entries > provide a > subquery number that is related back to the .selecttrace output. (user: > drh tags: reuse- > subqueries) I confirm that there is a slight slowdown here. But for me, this bisect lands on the same check-in: https://sqlite.org/src/info/e130319317e76119 This is the bisect: https://sqlite.org/src/timeline?bid=y736b53f57fn03f2e78899y8eb62fd5fan9cf8ebd141n0888fc2e88y4cdcda408ay6821c61f1dy4678cb1044n0465d2fc0dn5c188361a9nb57c545a38ne130319317yf856676c84 -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
