[sqlite] Wal index format questions

) Thanks! Harmen ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Salt endianness

re all unsigned integers in the native byte-order of the host machine" So I guess that's not true for the salt1 and salt2 values? They are to be interpreted as either bigendian? Thanks! Harmen ___ sqlite-users mailing list sqlite-users@mailingl

[sqlite] Order of applying subquery in SELECT statement

, Harmen ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashes

> (1) Recompile with the following compile-time options: -DSQLITE_DEBUG > -DSQLITE_OMIT_LOOKASIDE > > (2) Enable whatever AddressSanitizer tools > (https://en.wikipedia.org/wiki/AddressSanitizer) you have available on your > platform, in addition to (1) above. > > (3) If you do not have an

[sqlite] SQLite crashes

egards, Harmen

[sqlite] SQLite PENDING lock before SHARED lock with WAL enabled

-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Harmen de Jong - CoachR Group B.V. Sent: donderdag 18 juni 2015 15:02 To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLite PENDING lock before SHARED lock with WAL enabled

[sqlite] SQLite PENDING lock before SHARED lock with WAL enabled

schema can cost a lot of time (relatively). Therefore, we would like to be able to open multiple parallel connections and initialize them at the same time. Do you have any suggestions for this? Best regards, Harmen de Jong -Original Message- From: sqlite-users-bounces

[sqlite] SQLite PENDING lock before SHARED lock with WAL enabled

f138, const char * * pzTail=0x0cd6f144) Line 105215 SQLService.exe!sqlite3_exec(sqlite3 * db=0x0e427e38, const char * zSql=0x0141a4c4, int (void *, int, char * *, char * *) * xCallback=0x, void * pArg=0x, char * * pzErrMsg=0x) Line 100638 Best regards, Ha

Re: [sqlite] Encrypted database

management tools too. Best regards, Harmen de Jong CoachR Group B.V. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Brown, Matthew Sent: maandag 15 december 2014 17:05 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Encrypted

Re: [sqlite] Any interest for open source multi-user 'SQLite database server' application?

r app. Best regards, Harmen de Jong ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Any interest for open source multi-user 'SQLite database server' application?

t us know if you would be interested in this project! Best regards, Harmen de Jong CoachR Group B.V. www.CoachRDevelopment.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug where query does not give a result while it should

-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Kennedy Sent: woensdag 18 december 2013 16:23 To: General Discussion of SQLite Database Subject: Re: [sqlite] Bug where query does not give a result while it should >> Are

[sqlite] Bug where query does not give a result while it should

for some reason the NOT IN keyword does not work correctly. We created a test database that can be downloaded here: http://www.coachrdevelopment.com/share/querybug.zip . Are we missing something, or is this a bug? Best regards, Harmen de Jong CoachR Group B.V

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

>Harmen de Jong - CoachR Group B.V. wrote: >> http://www.coachrdevelopment.com/share/callstack_tree.html >> >> This shows most time is spend on sqlite3CodeRowTriggerDirect. > >I'd guess the actual culprit is the loop in getRowTrigger (which does >not show up because

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 12 sep. 2013, at 07:20, "James K. Lowden" <jklow...@schemamania.org<mailto:jklow...@schemamania.org>> wrote: On Tue, 10 Sep 2013 12:58:21 + Harmen de Jong - CoachR Group B.V. <har...@coachr.com<mailto:har...@coachr.com>> wrote: I think the way I wro

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

. We don't see it yet. Looking forward to any suggestions. Best regards, Harmen ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

is function is causing the polynomial increase in time and if so, WHY it causes a polynomial increase in time and if there are any optimizations possible. We don't see it yet. Looking forward to any suggestions. Best regards, Harmen ___ sqlite-users mai

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 21:24, "E.Pasma" wrote: > My suppositions that the time was spent in the execute step and that this has > been fixed in the new release appeared both wrong. Thus I may be wrong again > but I think to have an explanation now. > It is as Simon guesses

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 21:24, "E.Pasma" <pasm...@concepts.nl> wrote: > Op 10 sep 2013, om 19:48 heeft Simon Slavin het volgende geschreven: > >> >> On 10 Sep 2013, at 4:15pm, Harmen de Jong - CoachR Group B.V. >> <har...@coachr.com> wrote: >>

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 16:44, "E.Pasma" <pasm...@concepts.nl> wrote: > Op 10 sep 2013, om 16:36 heeft Harmen de Jong - CoachR Group B.V. het > volgende geschreven: > >> On 10 sep. 2013, at 16:16, "E.Pasma" <pasm...@concepts.nl> wrote: >> >&

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

Sent from my iPad On 10 sep. 2013, at 17:04, "Keith Medcalf" wrote: >>> No, it is all about preparing, so there is no need to insert data. >>> When we perform the query "delete from A where id=1;" on the >>> databases from the zip file, we get the following timings: >>>

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 16:16, "E.Pasma" <pasm...@concepts.nl> wrote: > Op 10 sep 2013, om 11:37 heeft Harmen de Jong - CoachR Group B.V. het > volgende geschreven: >> I included 5 databases that we used for testing in this link: >> http://wikisend.com/

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 15:41, "Igor Tandetnik" wrote: > Not exponential - polynomial. Between 500 and 1 the size of input > increases x20, so the time increase of x400 would be consistent with a > quadratic algorithm. Your observed measurements are even better than that.

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 14:43, "E.Pasma" 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 >

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 10 sep. 2013, at 11:37, "Harmen de Jong - CoachR Group B.V." <har...@coachr.com> wrote: > As you can see this is an exponential growth in time it takes to execte the > query. So far we're missing the point of why this growth should be > exponential. We tri

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

On 9 sep. 2013, at 22:11, "E.Pasma" wrote: > Ha, I did not mean the length of the names but the length of the hash table > (NL: klutstabel), That is the number of buckets over which the hash values > are distributed. I looked some further in the code and now believe that

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

case if there were any joins, but there are none. Does any one have any other explanation to why the performance gets so bad when having many tables? Our table and column names are not too long either as E.Pasma suggests. Best regards, Harmen ___ sqlit

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

me to that thread, but as dr. Hipp states in this thread, the tables are stored in a hash. Therefore I would not expect a large performance decrease on large number of tables at all, or am I missing something? Best regards, Harmen ___ sqlite-use

Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables

thereby hiding application crashes from the users (which access the app through a web interface). -Automatically backing up the DB in compressed and encrypted format. Best regards, Harmen ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite

[sqlite] Query preperation time does not scale linearly with growth of no. of tables

time of the query is scaling up so fast in the above examples? Best regards, Harmen de Jong CoachR Group B.V. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users