On Mon, Dec 31, 2012 at 8:13 PM, Ward Willats wrote:
>
> On Dec 31, 2012, at 12:57 AM, Simon Slavin wrote:
>
> >
> > On 31 Dec 2012, at 8:54am, Igor Korot wrote:
> >
> >> I simply forgot to do it on the table creation. And now
On 12/31/2012 11:03 AM, Cory Isaacson wrote:
We are doing some basic tests of SQLite4, and the performance seems slow. We
also tested LSM directly and got about the same results. The test is using
an INSERT of two integers, or 2 strings in LSM. It starts at around 9000
INSERTs/second, then
On 31 Dec 2012, at 9:13pm, Roger Binns wrote:
> You should create the indexes after inserting the data. If you don't you
> end up with index data and row data intermingled in the database which
> makes things slower.
>
> Journaling off definitely worked for me when I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/12/12 12:33, Michael Black wrote:
> Journaling off might work if you don't have any indexes.
You should create the indexes after inserting the data. If you don't you
end up with index data and row data intermingled in the database which
makes
I turned journalling off in my test program and sqlite3 is running about
3000/inserts per second right now at around 6M records. Lousy performance
compared to WAL mode.
journal=memory behaved the same way.
Journaling off might work if you don't have any indexes.
Taking the primary key off of my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/12/12 10:35, Michael Black wrote:
> One transaction like you did is best.
>
> I recently ran a test which ran pretty well with a commit every 1M
> records. Doing every 100,000 records slowed things down dramatically.
If you are creating the
One transaction like you did is best.
I recently ran a test which ran pretty well with a commit every 1M records.
Doing every 100,000 records slowed things down dramatically.
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of
Very impressive. With SQLite 3.7.14.1
Took 4 minutes to load a 1.5GB MySQL dump with 7.8 million records.
Count(*) takes 5 seconds. Even runs on a USB key. Wow!
Also loaded a smaller one (33MB database [30 tables/dumps] in 10
seconds, largest file had 200,000 records).
I wrapped the 7.8
On Dec 31, 2012, at 12:57 AM, Simon Slavin wrote:
>
> On 31 Dec 2012, at 8:54am, Igor Korot wrote:
>
>> I simply forgot to do it on the table creation. And now the table has
>> many rows...
>
> You can easily modify a TABLE definition or even an
Do we still get to report bugs?
I checked out the fossil repository
fossil clone http://www.sqlite.org/src4 sqlite4.fossil
I tried my insert test and ran into a problem.
I'm running Redhat 5.7 gcc 4.4.4
This program dies (showing inserts/sec)
123536
113110
110154
107018
105489
100335
On 31 Dec 2012, at 4:03am, Cory Isaacson wrote:
> We are doing some basic tests of SQLite4, and the performance seems slow. We
> also tested LSM directly and got about the same results. The test is using
> an INSERT of two integers, or 2 strings in LSM. It starts at
We are doing some basic tests of SQLite4, and the performance seems slow. We
also tested LSM directly and got about the same results. The test is using
an INSERT of two integers, or 2 strings in LSM. It starts at around 9000
INSERTs/second, then degrades to around 5000 INSERTS/second.
Both tests
Hi, ALL,
I want to wish all of you Happy New Year!
So that all you problems will be left in 2012 and everything you wish
for will take place in 2013.
Happy coding!!!
Thank you.
___
sqlite-users mailing list
sqlite-users@sqlite.org
On 31 Dec 2012, at 8:54am, Igor Korot wrote:
> I simply forgot to do it on the table creation. And now the table has
> many rows...
You can easily modify a TABLE definition or even an entire database by using
the SQLite shell tool to dump the database as text file of SQL
Hi, ALL,
Subj, please.
I simply forgot to do it on the table creation. And now the table has
many rows...
Thank you.
P.S.: Maybe it is somehow possible to do with "CREATE INDEX..."?
___
sqlite-users mailing list
sqlite-users@sqlite.org
15 matches
Mail list logo