On Thu, Jan 19, 2012 at 8:03 AM, Richard Hipp <d...@sqlite.org> wrote:
> On Thu, Jan 19, 2012 at 7:51 AM, John Elrick <john.elr...@fenestra.com > >wrote: > > > Interesting: > > > > 1. There are no database schema changes occurring after the system is > fully > > initialized > > 2. There are no ATTACHed databases (we checked that earlier) > > 3. There are no calls to VACUUM > > 4. As far as I am aware, there are no changes to any callbacks after the > > system is fully initialized. > > > > I believe your earlier note is pointing us in the right direction. > > Examining my call stacks, it appears that the query is being reparsed on > > every call to step. The question is, why? Did any of these conditions > > change between 3.6.17 and 3.7.9? Maybe we are doing something that is > > unintentionally triggering the re-parse which did not do so in the > earlier > > version. > > > > > Also: Changing a bound parameter on the right-hand side of a LIKE or GLOB > operator forces a reprepare of that one statement, so that the query > optimizer can determine if the new value meets certain criteria for > optimization. > > Try setting a breakpoint on sqlite3ExpirePreparedStatements() to see what > you find. Also, on these lines to check for statement expiration due to > variable rebinding: > > http://www.sqlite.org/src/artifact/3662b6a468a2?ln=1024 > http://www.sqlite.org/src/artifact/3662b6a468a2?ln=129 > > > I've been reading through the code. Do I understand correctly that if one prepared statement binding is changed in such a way as may influence the choice of the query plan that all the prepared statements for that database connection are flagged for being re-prepared? SQLITE_PRIVATE void sqlite3ExpirePreparedStatements(sqlite3 *db){ Vdbe *p; for(p = db->pVdbe; p; p=p->pNext){ p->expired = 1; } } > > > > > > On Thu, Jan 19, 2012 at 7:45 AM, Richard Hipp <d...@sqlite.org> wrote: > > > > > On Thu, Jan 19, 2012 at 7:41 AM, John Elrick <john.elr...@fenestra.com > > > >wrote: > > > > > > > Question: > > > > > > > > If a query has already been prepared with sqlite3_prepare_v2, why > would > > > > sqlite3_step need to call sqlite3Prepare, which in turn calls > > > > sqlite3RunParser? > > > > > > > > > > Because the database schema changed. Or because you ran ATTACH or > > VACUUM, > > > either of which could potential change the bytecode necessary to run > the > > > statement. Or, because you changed the authorization callback. > > > > > > > > > > > > > _______________________________________________ > > > > sqlite-users mailing list > > > > sqlite-users@sqlite.org > > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > > > > > > -- > > > D. Richard Hipp > > > d...@sqlite.org > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > -- > > John Elrick > > Fenestra Technologies > > 540-868-1377 > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- John Elrick Fenestra Technologies 540-868-1377 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users