On Mon, Nov 8, 2010 at 2:44 AM, Simon Slavin <[email protected]> wrote:
> Several bugs I've been reading about here seem to be cases where the query > optimizer works differently between one version of SQLite and the next. So > I wondered whether it would be possible for the testing suite to log the > amount of time taken for each operation, leading to a long series of > timings. Then, once the build has passed all the tests, the timings for the > new version could be compared to the timings for the previous version. Any > discrepancies unexpected in amount or direction could then be explored. > > Simon, also thought about something like this when all those timing issues appeared in the list. I'm sure the sqlite developers will find the way how it is best to implement this, just my random thoughts. This test suite at least for some of the problems posted can be just a record of a table with the following fields: - the queries to create the tables and indexes. - the minumum number of "insert .. default values" queries for every table created (this will save from saving the actual user data). I suppose for many joins if the planner failed to optimize effectively, the difference should be noticeable even with all those Nulls coming from "insert .. default values". - the query in question. So the test suite can just step through all the records from the table above. For one record it just creates the db twice, measuring the timings for one version and another. if the difference is significant, then stop, otherwise go further. Max Vlasov _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
