Joe Wilson wrote:
SQLite is extremely fast in most area of SQL functionality except for
bulk inserts of non-ordered data into multi-indexes tables, where it
is very slow.
Are you sure that it's really "very slow" compared to other database
engines? How does its insert speed compare to mySQL, PostgreSQL, Orcale,
DB2, Firebird, etc. for large bulk inserts?
why should the user have to pre-sort
data to achieve acceptable performance?
Most users don't have to do this, and are happy with the insert speed.
It is only a few users who are pushing SQLite, and probably other
database engines, to their limits that need to resort to such tricks to
get it to run as fast as possible.
In the current SQLite insert algorithm there's way too much shuffling
around of disk pages in order to minimize database footprint at
all costs. There ought to be a PRAGMA to prefer maximizing insert
speed when inserting, and if it doubles or quadruples the database
size - so be it. Most embedded devices may opt for minimum space; but
most PC-based apps would likely opt for maximum insert speed.
I'm not sure the number of users for whom this is an issue warrants
adding a second code path to sqlite.
It might make sense to create a separate standalone utility program
(like sqlite3_analyzer) that reuses some the sqlite source to do bulk
inserts into a table in a database file as fast a possible with out
having to worry about locking or journaling etc.
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
