Re: [sqlite] Compressed schema in memory?

On 3/16/17, Bob Friesenhahn wrote: > In sqlite_master I see quite a lot of "sql_autoindex" indexes. Do > these auto indexes consume the same RAM as explicit indexes? Yes. Those indexes are implementing UNIQUE constraints. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] Compressed schema in memory?

On 3/16/17, Bob Friesenhahn wrote: > > I just checked and the total character count for the trigger and index > names themselves is only 23k, which is not even a tiny dent in 1.58MB. > Is there a muliplying factor somewhere which would make this worth > doing? I did

Re: [sqlite] Compressed schema in memory?

In sqlite_master I see quite a lot of "sql_autoindex" indexes. Do these auto indexes consume the same RAM as explicit indexes? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [sqlite] Compressed schema in memory?

On Thu, 16 Mar 2017, Richard Hipp wrote: One thing you can do right away to save space is pick shorter names for your 650 triggers an d indexes. SQLite stores the full name. But as these names are not (normally) used by DML statements, you can call them whatever you want. I'm showing your

Re: [sqlite] Compressed schema in memory?

On Thu, 16 Mar 2017, Richard Hipp wrote: Your 664K is a conservative estimate. On my (64-bit linux) desktop, I'm showing 1.58MB of heap space used to store the schema. (Hint: bring up the database in the command-line shell, load the schema by doing something like ".tables", then type

Re: [sqlite] Compressed schema in memory?

On 3/16/17, Bob Friesenhahn wrote: > > I shared our database privately with Richard via email. > Your 664K is a conservative estimate. On my (64-bit linux) desktop, I'm showing 1.58MB of heap space used to store the schema. (Hint: bring up the database in the

Re: [sqlite] Compressed schema in memory?

On Thu, 16 Mar 2017, Richard Hipp wrote: On 3/16/17, Bob Friesenhahn wrote: The schema (already stripped to remove white space and comments) for our database has reached 664K Yikes. That's about 10x or 20x what we typically see. Are you able to share your

Re: [sqlite] Compressed schema in memory?

On 3/16/17, Bob Friesenhahn wrote: > > The schema (already stripped to remove white space and comments) for > our database has reached 664K Yikes. That's about 10x or 20x what we typically see. Are you able to share your schema with us? -- D. Richard Hipp

Re: [sqlite] Compressed schema in memory?

On 16 Mar 2017, at 8:09pm, Bob Friesenhahn wrote: > Would it be reasonably feasible to compress the per-connection schema data > (stored in RAM) and decompress it as needed? This would make > prepared-statement and possibly other operations a bit slower but if

[sqlite] Compressed schema in memory?

Would it be reasonably feasible to compress the per-connection schema data (stored in RAM) and decompress it as needed? This would make prepared-statement and possibly other operations a bit slower but if objects are compressed at sufficiently small granularity, then the per-connection memory

Re: [sqlite] Is it possible to change "synchronous" flag of ZIPVFS pager?

On 03/16/2017 05:00 PM, Tomasz Maj wrote: I have an application which work with many zipped databases in WAL journal mode and the databases are stored on a media of low write bandwidth. There is a problem that that fsync operations invoked from one thread are blocking other fsync operations

[sqlite] Shared cache mode and busy wait

Today I saw a APSW note about shared cache mode at "https://rogerbinns.github.io/apsw/tips.html#shared-cache-mode;, which led me to "https://sqlite.org/src/tktview/ebde3f66fc64e21e61ef2854ed1a36dfff884a2f;. Reading the sqlite page at "https://sqlite.org/sharedcache.html; I see that section

Re: [sqlite] Unable to clone fossil repo

I was running 1.33, which was the version available in Ubuntu 16.04's repos. Doing a quick download form the website took care of the issue. Thank you! On Thu, Mar 16, 2017 at 11:51 AM, Richard Hipp wrote: > On 3/16/17, Richard Hipp wrote: > > > > As of

Re: [sqlite] Unable to clone fossil repo

On 3/16/17, Richard Hipp wrote: > > As of 2017-03-12, you need Fossil 2.0 or later. What does "fossil -v" > say for you? > I gave you the wrong command. "fossil version", not "fossil -v". What does it show? -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] Unable to clone fossil repo

On 3/16/17, Charles Leifer wrote: > Hi, I'm attempting to clone the source tree using the instructions from the > website (http://www.sqlite.org/getthecode.html#clone), but I'm getting an > error when "Artifacts received" hits 58416: > > $ fossil clone

Re: [sqlite] Unable to clone fossil repo

Nevermind, I just needed to upgrade from 1.33 to 2.0. On Ubuntu 16.04 the system version is 1.33, but I was able to download the binary from the fossil-scm site and everything worked like a charm. Thanks for the amazing, free software! On Thu, Mar 16, 2017 at 7:02 AM, Charles Leifer

[sqlite] Unable to clone fossil repo

Hi, I'm attempting to clone the source tree using the instructions from the website (http://www.sqlite.org/getthecode.html#clone), but I'm getting an error when "Artifacts received" hits 58416: $ fossil clone http://www.sqlite.org/cgi/src sqlite.fossil Round-trips: 7 Artifacts sent: 0

Re: [sqlite] Is it possible to change "synchronous" flag of ZIPVFS pager?

I have an application which work with many zipped databases in WAL journal mode and the databases are stored on a media of low write bandwidth. There is a problem that that fsync operations invoked from one thread are blocking other fsync operations invoked from another thread. I think that

Re: [sqlite] Is it possible to change "synchronous" flag of ZIPVFS pager?

2017-03-16 9:51 GMT+01:00 Dan Kennedy : > On 03/16/2017 01:40 PM, Tomasz Maj wrote: > >> Hi, >> >> >> According to my observations, "PRAGMA synchronous=...;" query affects >> only the standard sqlite pager. But for zipped databases sqlite uses >> additional ZIPVFS pager

Re: [sqlite] Is it possible to change "synchronous" flag of ZIPVFS pager?

On 03/16/2017 01:40 PM, Tomasz Maj wrote: Hi, According to my observations, "PRAGMA synchronous=...;" query affects only the standard sqlite pager. But for zipped databases sqlite uses additional ZIPVFS pager layer which actually decide whether and when to sync content of files associated

Re: [sqlite] last_insert_rowid and FTS in 3.17

On Thu, Mar 16, 2017, at 03:25 AM, Keith Medcalf wrote: > > Head of trunk certainly fixes it ... > > SQLite version 3.18.0 2017-03-15 19:11:29 > Enter ".help" for usage hints. > Connected to a transient in-memory database. > Use ".open FILENAME" to reopen on a persistent database. > sqlite>

[sqlite] Is it possible to change "synchronous" flag of ZIPVFS pager?

Hi, According to my observations, "PRAGMA synchronous=...;" query affects only the standard sqlite pager. But for zipped databases sqlite uses additional ZIPVFS pager layer which actually decide whether and when to sync content of files associated with a database. It looks like "PRAGMA