Hi Mr. Smith, Quote :"(though, SQLite successive iterations usually become faster, not slower, apart from compile-time options that may be different)."
That's what concerns me as well, but since I'm a recent user of SQlite type database and sqlite3 I prefer blaming me for those differences. Since I'm working on confidential/sensitive data, I need to take some time to process your reply and see what can I show you guys and I can't. First of all, I'll check all the pragmas and stuff, plus the version of SQliteBrowser (former DB Browser for SQlite indeed) I'm using, etc. I'll try to come back at you asap 2016-09-07 16:24 GMT+02:00 R Smith <rsm...@rsweb.co.za>: > > > On 2016/09/07 2:53 PM, Laura BERGOENS wrote: > >> Hello everyone, >> >> I tried to get some answers using the mailing list archives, but you guys >> have been communicating so much on this, it's hard to run through >> everything that was written ;) >> >> Basically, I'm using sqlite3 in my C application. I believe the tool >> SQLiteBrowser is using it as well. >> > > Yes, though the versions might be hugely different. Further to this (and > regarding the rest of your post), SQLitebrowser sounds like the name it > used to have before it became "DB Browser for SQLite" quite some time ago, > perhaps you'd want to update to the latest to be sure the differences are > real (though, SQLite successive iterations usually become faster, not > slower, apart from compile-time options that may be different). > > To find out the exact difference, you can SELECT the following: > sqlite_version() > sqlite_source_id() > > and this query will tell which options were compiled-in: > PRAGMA compile_options;* > > *If the new version is truly slower, then the most likely culprit is a > regression for an optimization (or a regression introduced by an > optimization, compile-time option or new functionality) that causes the > current version to perform less quick than a previous version. If this is > the case, we would definitely like to know about it. Could you supply the > Schema and query (at a minimum) and perhaps upload the DB somewhere (if the > data is not too sensitive). > > Further to this, a 100-second query on a DB the size you describe is > ludicrous, even for terribly formulated queries - if this is in fact a > normal situation (i.e. not an obvious regression), might we have a go at > your query to see if it could possibly be optimized? > * > *Thanks, > Ryan > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Laura BERGOENS Technicienne supérieure en Informatique et étudiante à l'IMERIR de Perpignan *Institut Méditerranéen d'Étude etde Recherche en Informatique* _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
