Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

>> Whether and how you can do so will depend on what operating system you are using. I am using a CentOS 6.4 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

Whether and how you can do so will depend on what operating system you are using. On 27 October 2013 16:10, Raheel Gupta wrote: > Hi, > > Yes, I tried Valgrind and it shows no leaks. > But why would this happen with 64K pages ? In 1024 Sqlite is able to > release all the

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

Hi, Yes, I tried Valgrind and it shows no leaks. But why would this happen with 64K pages ? In 1024 Sqlite is able to release all the memory. >> It might also be that your memory allocator is holding onto freed memory rather than releasing it back to the OS. How should I free it ? On Sun,

[sqlite] System.Data.SQLite version 1.0.89.0 released

System.Data.SQLite version 1.0.89.0 (with SQLite 3.8.1) is now available on the System.Data.SQLite website: http://system.data.sqlite.org/ Further information about this release can be seen at http://system.data.sqlite.org/index.html/doc/trunk/www/news.wiki Please post on the SQLite

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

On Sun, Oct 27, 2013 at 12:02 AM, Raheel Gupta wrote: > Hi, > > Sir, if you see my first email, I have already tried that. When the 15 > Million records are being outputted, the ram usage shoots to a MAX of > 126MB. After the "PRAGMA shrink_memory" it goes down to 65Mb but

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

Hi, Sir, if you see my first email, I have already tried that. When the 15 Million records are being outputted, the ram usage shoots to a MAX of 126MB. After the "PRAGMA shrink_memory" it goes down to 65Mb but doesnt go below that. On Sun, Oct 27, 2013 at 4:55 AM, Richard Hipp

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

>> Try letting SQLite use its default for your platform. The default when the database is created is 1024. It works well in that page size as I have mentioned in my first email. The issue is with 65536. Why should there be a memory leak when the page size is 65536 ? I have to use 65536 to enable

Re: [sqlite] incredibly minor documentation bug

On Sat, Oct 26, 2013 at 12:30 PM, George Collins wrote: > > "If X is the integer -9223372036854775807 then abs(X) throws an integer > overflow error since there is no equivalent positive 64-bit two complement > value." > > It's off by one: X is actually

Re: [sqlite] Tool for extracting deleted data from unvacuumed SQLite files

Hello everyone, I've released v0.4 of Undark last night. Improves on the extraction of data out of the freeblocks as well as now allowing for blob dumps that extend beyond a single page. Also added an option to let you specify the DB page size for when

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

On Sat, Oct 26, 2013 at 3:03 PM, Raheel Gupta wrote: > > This leads me to conclude that there is some kind of Memory Leakage when > the page size is 64K. > > How can I bring down the memory usage atleast when I shrink_memory after > the query executes. > Doubtful.

Re: [sqlite] SQlite Memory Leakage with 65536 Page Size

On 26 Oct 2013, at 8:03pm, Raheel Gupta wrote: > How can I bring down the memory usage atleast when I shrink_memory after > the query executes. You stop using such big pages. Try letting SQLite use its default for your platform. Do an export and reimport without using

[sqlite] SQlite Memory Leakage with 65536 Page Size

Hi, I am using a Page Size of 65536 and I have found the performance good enough for me until now. I have the database having the following table: CREATE TABLE map ( n BIGINT NOT NULL DEFAULT 0, s INT(5) NOT NULL DEFAULT 0, d INT(5) NOT NULL DEFAULT 0, c INT(1) NOT NULL DEFAULT 0, b UNSIGNED

Re: [sqlite] SQLite keeps on searching endlessly

Hi, The index of (d,n,s) has improved the performance and is WAY better than (n,s,d) Thanks to everyone for helping me out. >> So which is better ? An Index or a Primary Key ? My index is not unique and hence I guess going to Primary Keys would slow down inserts quite a lot. Please correct me

Re: [sqlite] possible join bug/regression with sqlite-3.8.1

On Sat, Oct 26, 2013 at 6:17 PM, Richard Hipp wrote: > > We are looking into the problem. > > Meanwhile, I noticed some rather egregious inefficiencies in the XBMC > schema and would like to contract the XBMC developers about this. I spent > 5 minutes clicking around on various

[sqlite] incredibly minor documentation bug

Don't ask me what use case made me notice this, but the http://www.sqlite.org/lang_corefunc.html documentation for abs(), as of 12:29PM EDT on 10/26/2013, is only about 99.89157978275145% accurate. "If X is the integer -9223372036854775807 then abs(X) throws an integer overflow

Re: [sqlite] possible join bug/regression with sqlite-3.8.1

On Sat, Oct 26, 2013 at 11:17 AM, Ferdinand Hübner < ferdinand.hueb...@gmail.com> wrote: > > Please note that I'm just an xbmc user, not a developer. > We are looking into the problem. Meanwhile, I noticed some rather egregious inefficiencies in the XBMC schema and would like to contract the

Re: [sqlite] possible join bug/regression with sqlite-3.8.1

On 26 Oct 2013, at 4:17pm, Ferdinand Hübner wrote: > If you need any more information, don't hesitate to ask. Ignoring the fact that two different versions of SQLite give different results, for a minute, can you answer these questions: Is one of these results

[sqlite] possible join bug/regression with sqlite-3.8.1

Hello, A query against the xbmc database doesn't return results anymore when sqlite-3.8.1 is used. With sqlite-3.8.0.2, the query returns results against the identical database just fine. Please note that I'm just an xbmc user, not a developer. It's been quite a while since I last posted to a