At 15:27 07/01/2006, [EMAIL PROTECTED] wrote:
"Shailesh N. Humbad" <[EMAIL PROTECTED]> wrote:
> I wrote an article suggesting a method for improving concurrency in
> SQLite. The main reason I wrote this article is so I can understand
> SQLite better, not because my proposal is new or usable. I am not an
.......
And, as the author of the paper notes, you can already accomplish
the same thing by putting the various tables in separate
database files then using ATTACH to bring them all into the
same database connection.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Can any part of the backend, btree, pager or os interface; separate
each table in multiple files automatically? Can those files reside on
2 or more disks (memory based or hd based)? This way the sqlite
problem :(cite from "[EMAIL PROTECTED]" Subject:"Re: [sqlite] Slowness
with in-memory database" 21/12/2005)
Transactions are slow due to limitations of computer disk hardware.
When SQLite writes to the disk, it has to stop and wait at a couple of
places to for all of the data to actually be written to the disk
surface. This is necessary in case a power failure or OS crash occurs -
so that the data can be recovered. It is this stopping and waiting that
takes so long. If we didn't need to wait for the disk platter to
spin underneath the head, SQLite could easily handle tens of thousands
of transactions per second. But because each transaction requires at
least two revolutions of the disk platter, SQLite is limited to about
60 transactions per second. (Do the math: 7200 RPM disk drive means
120 revolutions per second. 2 complete revolutions per transaction ->
60 transactions per second.)
(end cite)
can get better?. Note i don't say partitions or slices.
------------------------------------------------------------
Alien.org contacted... waiting for Ripley
