On Tue, Dec 26, 2006 at 09:36:42AM -0800, Ken wrote:
> > Your question boils down to this: Can you speed up transactions
> > by dropping the durable property - the D in ACID. Yes you
> > can. Actually, most client/server database engines already
> > do this for you without telling you. Very few
Regarding Oracle:
It also batches commits... This means that if two or more users submit commits
concurrently (or near the same interupt ) then those will be serviced at the
same time.
But oracle differs significantly from sqlite, in its architecture as it would
not be appropriate for an
[EMAIL PROTECTED] uttered:
It takes at least two complete rotations of the disk platter
to do an atomic and durable commit. On a 7200 RPM disk, that
means 60 transactions per second is your speed of light.
Your question boils down to this: Can you speed up transactions
by dropping the durabl
Laszlo Elteto wrote:
Nested transactions would solve my problem - but only if it worked across
different connections. As I said there are many transactions from various
clients, they may use multiple connections (eg. on a server). I think nested
transactions would still be for ONE particular conn
On Wed, Dec 20, 2006 at 01:22:06PM -0500, Laszlo Elteto wrote:
> Nested transactions would solve my problem - but only if it worked across
> different connections. As I said there are many transactions from various
> clients, they may use multiple connections (eg. on a server). I think nested
> tra
Elteto
-Original Message-
From: Nicolas Williams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 20, 2006 9:43 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On Wed, Dec 20, 2006 at 02:01:12AM +, [EMAIL PROTECTED] wrote:
> Laszlo Elteto <
It is the same problem as trying to get a quart out of a pint bottle.
People looking for durability and higher performance might find that
using 15,000 RPM disks will do it without affecting durability or
requiring an application redesign. Experimentation with multiple disk
spindles so that S
On Wed, Dec 20, 2006 at 02:01:12AM +, [EMAIL PROTECTED] wrote:
> Laszlo Elteto <[EMAIL PROTECTED]> wrote:
> > I DO need Durability, so I don't want to drop that. In fact, I need and want
> > normal transactional updates - just not immediately flushed to disk.
>
> If the information is not flu
this type of code modification on SQLite :(
Probably I will need to do it myself...
Laszlo Elteto
-Original Message-
From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 9:02 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On 12/
On 12/19/06, Laszlo Elteto <[EMAIL PROTECTED]> wrote:
For this particular application it would NOT be a problem to lose like 2-5
seconds of transactions. I wonder if it is possible to tell SQLite to "hold
off" the transactions, ACCUMMULATE them until a certain time (or if cache
memory is exhauste
Laszlo Elteto <[EMAIL PROTECTED]> wrote:
> I DO need Durability, so I don't want to drop that. In fact, I need and want
> normal transactional updates - just not immediately flushed to disk.
If the information is not flushed to disk, how can it be durable?
--
D. Richard Hipp <[EMAIL PROTECTED]>
ECTED]
Sent: Tuesday, December 19, 2006 12:08 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On Tue, 19 Dec 2006 13:52:19 -0500, you wrote:
>I've started to use SQLite and it works fine - except for performance.
>The application gets requests (possibly
m several other
threads, then finish it from yet another thread.
Laszlo Elteto
SafeNet, Inc.
-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 11:30 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
Laszlo Elte
So I don't have
to do the work myself IF it's already been done.)
Laszlo Elteto
SafeNet, Inc.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 11:15 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transac
On Tue, 19 Dec 2006 13:52:19 -0500, you wrote:
>I've started to use SQLite and it works fine - except for performance. The
>application gets requests (possibly from many users) and does a few
>transactions on the database. (eg. create a context for the request; later
>it may be updated and when th
Laszlo Elteto wrote:
For this particular application it would NOT be a problem to lose like 2-5
seconds of transactions. I wonder if it is possible to tell SQLite to "hold
off" the transactions, ACCUMMULATE them until a certain time (or if cache
memory is exhausted - which is not yet the case as
Laszlo Elteto <[EMAIL PROTECTED]> wrote:
> I've started to use SQLite and it works fine - except for performance. The
> application gets requests (possibly from many users) and does a few
> transactions on the database. (eg. create a context for the request; later
> it may be updated and when the u
I've started to use SQLite and it works fine - except for performance. The
application gets requests (possibly from many users) and does a few
transactions on the database. (eg. create a context for the request; later
it may be updated and when the user releases the record is deleted.)
I tried all
18 matches
Mail list logo