You canot have constant time inserts into a B-Tree because of the
inherent nature of the algorithm. Berkeley DB has either B-Tree or
hashed indices. The unordered hashed indices are possibly what you
measured. Note that B-Trees have the additional property that they
maintain an order and
Unless I did something wrong, I did observe constant time inserts in
Berkeley DB. Is it possible that I had constant time inserts into a btree
as my db grew because of the nature of my data? I was inserting records in
order of how they would be sorted by index. In other words, every inserted
On Oct 29, 2008, at 4:59 AM, Julian Bui wrote:
> Hi everyone,
>
> First off, I'm a database and sqlite newbie. I'm inserting many many
> records and indexing over one of the double attributes. I am seeing
> my insert times slowly degrade as the database grows in size until
> it's unacceptable
>
> See "PRAGMA cache_size". If you're working on a modern desktop with
> a comfortable amount of RAM, it isn't unreasonable to increase the
> cache size by an order of magnitude or two (default is 2000).
>
I forgot to mention I use JDBC to access sqlite from a java app. Is there
an
Thanks for replies everyone.
Actually, I don't include the code but I do make a very small mention of
using batch inserts w/ a transaction ("> //every dataInsertPs gets added to
a batch and committed every 1000 records").
I am using JDBC so I do not use BEGIN and END statements. Do I need to
On Wed, Oct 29, 2008 at 06:10:56AM -0600, John Stanton scratched on the wall:
> The Sqlite B-Tree indices do slow down on insertion as extra levels are
> created in the index as it grows large. That is an inherent feature of
> such structures.
This can often be mitigated by increasing the
Eduardo Morras wrote:
> At 13:10 29/10/2008, you wrote:
>
>> Look up the implications of Sqlite's ACID feature and the use of
>> transactions. COMMITs are tied to disk rotation speed. On our Sqlite
>> databases where we look for performance we use 15,000 rpm disks and are
>> diligent in
At 13:10 29/10/2008, you wrote:
>Look up the implications of Sqlite's ACID feature and the use of
>transactions. COMMITs are tied to disk rotation speed. On our Sqlite
>databases where we look for performance we use 15,000 rpm disks and are
>diligent in wrapping INSERTs, UPDATEs and DELETEs in
Look up the implications of Sqlite's ACID feature and the use of
transactions. COMMITs are tied to disk rotation speed. On our Sqlite
databases where we look for performance we use 15,000 rpm disks and are
diligent in wrapping INSERTs, UPDATEs and DELETEs in transactions and
get very good
The most common reason which comes up here time and again is that the
inserts are wrapped in a transaction. See BEGIN, END statements in the
Docs. You haven't mentioned whether you are using a transaction, so I
may be misguided in my reply. But the sample code doesn't!
Wednesday, October 29,
Hi everyone,
First off, I'm a database and sqlite newbie. I'm inserting many many
records and indexing over one of the double attributes. I am seeing
my insert times slowly degrade as the database grows in size until
it's unacceptable - less than 1 write per millisecond (other databases
have
11 matches
Mail list logo
