Very interesting. 2 questions -

(1) On the SQLite Download page - the Linux version just says "x86" while
the Windows version is "Win-32 x86". Does this mean that the Linux version
is a 64-bit version? In other words - if run on, say, RedHat 5.5 64-bit -
it will be able to use >4GB of RAM?

(2) On Windows - a RamDisk "drive letter" can be used beneficially in 2
ways -
(a) to contain the database itself
(b) to serve as a destination for the TEMP and TMP - which SQLite (through
Windows I suppose) uses often as a scratchpad.
Is it possible - good/bad idea - to point the Windows TMP and TEMP to a
"virtual" drive letter on top of a RamDisk? The RamDisk gets established as
Windows comes up - but the question is whether Windows might need the TMP /
TEMP prior to that point in time - when they are not yet going to be
available - causing startup problems?

On Sat, Mar 24, 2012 at 5:36 PM, Roger Binns <rog...@rogerbinns.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24/03/12 13:48, Udi Karni wrote:
> > I tried the SQLite in-memory DB feature - but when it exceeded about
> > 2GB - I got the "out of memory" message.
>
> Technically it ran out of address space, not ram.
>
> > In my particular scenario - while the raw data being attached and read
> > is hundreds of GB - the result sets are only a few GB.
>
> 2GB is the threshold to switch to 64 bits.  Also note that SQLite does not
> calculate the entire result set in advance.  Instead when you call
> sqlite3_step() it does whatever work is necessary to find the next result
> row.  It is only if you do something like require sorting that cannot be
> satisfied by an index that the whole result set has to be calculated and
> then sorted.
>
> > A 64-bit version of SQLite that could handle an in-memory DB of 5-10
> > GB would be quite useful and interesting to test.
>
> You can also use a ramdisk for the files with journalling turned off.
> Microsoft used to have one, but now a search shows a number of companies.
>  I have no idea which ones are the most reputable. Under Linux you can use
> tmpfs which makes things very easy.
>
> > Unfortunately I am not versed enough in compiling my own version - so
> > hopefully this would be offered one of these days.
>
> Unfortunately making the free Microsoft dev tools generate 64 bit binaries
> is a PITA.  Another alternative is to use a 64 bit version Linux in which
> case all this stuff just works.
>
> > Whether a RAM-only version would truly run subtantially faster than an
> > SSD-based DB - remains to be seen - but the <2GB experiments seem to
> > show that in-memory is quite promising.
>
> Any memory used to store databases is memory that cannot be used for I/O
> caching.
>
> Roger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk9uaHgACgkQmOOfHg372QQhXQCg0c7MYT5s9WBSGcwyYWra7ZNx
> 3qsAmwRSECp48Z2KkhfkMGvyvR7X1LsJ
> =M4tq
> -----END PGP SIGNATURE-----
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> 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

Reply via email to