I've tried that before but now I've found out I had empty "begin" implementation in my wrapper, now it works, thank you.
On Mon, Sep 5, 2011 at 6:59 PM, Dan Kennedy <danielk1...@gmail.com> wrote: > On 09/05/2011 10:47 PM, Rado Rado wrote: > >> I'm running simple prepared SELECT statement in loop ( about 3000 times ). >> It is something like "SELECT value FROM t WHERE t_id=? AND name=?". For >> most >> calls the row does not exist, step() returns SQLITE_DONE so I call reset >> after that(). The loop takes about 0.25 second and result seems to be >> correct. >> >> When I execute any SELECT query (using different table, like SELECT * FROM >> t2) which returns some row and I won't call reset() so it stays open, when >> I >> execute the loop described above after this, it is much faster (0.08 >> sec.). >> >> Is it because of some lock obtained for my process by opened statement? Or >> am i doing something wrong? >> > > It will be the overhead of obtaining a read lock. In the first case, > you are obtaining and releasing a database read lock (a system call) > 3000 times. In the second case, you are only doing it once. > > You could get the same effect by wrapping your loop in a BEGIN/COMMIT > block. > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
