The one aspect that I find usefull is for accessing a larger memory space.
For example on your typical linux (rh9 32bit) you start to run out of mem
(per process) at about 2gig. I can immediatly take the app an run on a
64bit machine and get at least an additional gig of ram from the
allocators.
Robert L Cochran wrote:
1. My wife, on her 32 bit Intel laptop, running Microsoft Access,
finds her system slowed down to a crawl whenever she works with one
table that has 109,000 rows. This is just the beginning of the huge
tables she creates. She has a bunch of others.
I moved this table to
Yes -- this is what I'm talking about.
Bob
Roger Binns wrote:
I think all this discussion has missed the original question.
Quite simply, is there any way in which the SQLite *source code* could
be changed in order to get better performance on 64 bit machines. If
there is then following
Version 3.1.0 (alpha) of SQLite is now available on the website.
Release notes are available from a link on the homepage.
This released is labeled alpha but it is still very well
tested. By being alpha it means that there is still a
small window of opportunity during when users can suggest
API
Any API changes?
On Fri, 21 Jan 2005 13:33:35 -0500, D. Richard Hipp [EMAIL PROTECTED] wrote:
Version 3.1.0 (alpha) of SQLite is now available on the website.
Release notes are available from a link on the homepage.
This released is labeled alpha but it is still very well
tested. By being
D. Richard Hipp wrote:
This released is labeled alpha but it is still very well
tested. By being alpha it means that there is still a
small window of opportunity during when users can suggest
API changes. Once we go to beta (in about a week) no more
changes will be accepted. So if you want to
D. Richard Hipp wrote:
This released is labeled alpha but it is still very well
tested. By being alpha it means that there is still a
small window of opportunity during when users can suggest
API changes. Once we go to beta (in about a week) no more
changes will be accepted. So if you want to
of all sqlite...16() functions.
- Michael
-Ursprüngliche Nachricht-
Von: D. Richard Hipp [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 21. Januar 2005 19:34
An: sqlite-users@sqlite.org
Betreff: [sqlite] Version 3.1.0
Version 3.1.0 (alpha) of SQLite is now available on the website
Eric,
Eric Scouten wrote:
D. Richard Hipp wrote:
This released is labeled alpha but it is still very well
tested. By being alpha it means that there is still a
small window of opportunity during when users can suggest
API changes. Once we go to beta (in about a week) no more
changes will be
Friday, January 21, 2005, 1:33:35 PM, DRH wrote:
Version 3.1.0 (alpha) of SQLite is now available on the website.
Compiling with MinGW MSYS on WinXP...
1. I had to modify my lib/tclConfig.sh to have
TCL_LIB_SPEC='-L/mingw/lib -ltcl84'
instead of
TCL_LIB_SPEC=''
or else testfixture wouldn't
Hi,
It would be nice if Autovacum can be set for a
database with data and also be set to occur at timely
intervals. Maybe something like every 1000 updates or
deletes.
__
Raymond Irving
--- D. Richard Hipp [EMAIL PROTECTED] wrote:
Version 3.1.0 (alpha) of SQLite is now available on
the
] Version 3.1.0
Version 3.1.0 (alpha) of SQLite is now available on the website.
Release notes are available from a link on the homepage.
This released is labeled alpha but it is still very well tested. By
being
alpha it means that there is still a small window of opportunity
during
when users can
Ulrik Petersen wrote:
Eric,
Eric Scouten wrote:
D. Richard Hipp wrote:
This released is labeled alpha but it is still very well
tested. By being alpha it means that there is still a
small window of opportunity during when users can suggest
API changes. Once we go to beta (in about a week) no
What if the autovacuum feature could be set based on a percent (pragma
autovacuum_percent?) of the unused file size (if known) ?
It could be useful to specify the fullness of data/keys of pages (pragma
table_full_percent?), this way an almost-readonly table could use the full
100% of the page. So
Doug Currie wrote:
Friday, January 21, 2005, 1:33:35 PM, DRH wrote:
Version 3.1.0 (alpha) of SQLite is now available on the website.
Compiling with MinGW MSYS on WinXP...
1. I had to modify my lib/tclConfig.sh to have
TCL_LIB_SPEC='-L/mingw/lib -ltcl84'
instead of
TCL_LIB_SPEC=''
or else
--- Doug Currie [EMAIL PROTECTED] wrote:
Friday, January 21, 2005, 1:33:35 PM, DRH wrote:
Version 3.1.0 (alpha) of SQLite is now available on the website.
Compiling with MinGW MSYS on WinXP...
1. I had to modify my lib/tclConfig.sh to have
TCL_LIB_SPEC='-L/mingw/lib -ltcl84'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd probably suggest something about how to set BLOB data from a void*
and an int in 1 line of code, if I had any idea at all how blob data is
set now.
I found an example, but it was something like 400 lines long, overly
complex (loading a blob into
Robert L Cochran wrote:
I should have indicated in my earlier post that magazines which do
side-by-side hardware testing are saying that the AMD Athlon 64 is
indeed faster than the Pentium 4; for example look in the January issue
of Maximum PC magazine. they have a followup test supplementing
I think all this discussion has missed the original question.
Quite simply, is there any way in which the SQLite *source code* could
be changed in order to get better performance on 64 bit machines. If
there is then following questions should be answered:
- Has it already been done (or should
Friday, January 21, 2005, 5:41:00 PM, Dan wrote:
autovacuum-ioerr2.4.0...
Error: error copying test.db to backup.db: no such file or
directory autovacuum-ioerr2-4.1.1...
Error: error copying backup.db to test.db: no such file or
directory autovacuum-ioerr2-4.1.2... Ok
20 matches
Mail list logo
