On 10 sep. 2013, at 14:43, "E.Pasma" <pasm...@concepts.nl> wrote:
> The timings do not look truly exponential to me. It looks more as if there is > a graduated charge (NL: staffeltoeslag) on the time per table. For instance: > table 1 - 500 - 2 msec/table > table 501 - 1.000 - 3 msec/table > table 1001 - 5.000 - 5 msec/table > table 5001 - 10.000 - 10 msec/table > It could be that there is no further extra charge above 10.000 tables. Is it > worth trying that or did you do that already? I'm sorry, but I think the way I wrote our timings were not that clear, since they are definately exponentially. The numbers from my previous post refer to the multiplier between the test cases. Just to make it clear, here follows the same tests, but then expressed in msec of total time per test. 500 tables - 10 msec in total 1000 tables - 25 msec in total 5000 tables - 298 msec in total 10000 tables - 985 msec in total > Your last observation, that the time is spent in sqlite3FKActions, means that > this is not in query preparation but in ecexution (if I understand the code > right). That is understandable because the engine needs to perform a vast > amount of internal internal queries to check all the related tables. sqlite3FKActions is part of the call stack create by sqlite3_prepare_v2, so I think it actually is part of the prepare. The execution time of sqlite3_step is actually negligible (< 1 msec) in our test cases because nothing is actually deleted because all tables are empty in the test case. > This leaves room for the hypothesis that the observed increase is a matter of > caching. For instance the sqlite default page cache may just fit 2.000 tables > but not 10.000. Is. It may be worth to try an increased cache_size. We already have a very high cache_size set in our test cases. We have set it to 819200, so I think that can be ruled out too. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
