On Tue, Jan 10, 2006 at 04:29:19PM -0300, Axel Mammes wrote:
> How about using a hard-link to store the log file somewhere else? That
> should work transparently...
Well, you can't hard-link across filesystems, but a symlink is exactly
what I was going to mention.
As for SQLite coming up with
How about using a hard-link to store the log file somewhere else? That
should work transparently...
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote:
> > >
> > > The short version:
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote:
> >
> > The short version:
> >
> > The first write operation writes the parts of the database that
> > are about to be overwritten to the journal file. If something
> > goes wrong during the
On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote:
>
>
> --- "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 09, 2006 at 06:47:04PM +0100, Eduardo wrote:
> > > of transactions per second. But because each transaction requires at
> > > least two revolutions of the disk
--- "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 09, 2006 at 06:47:04PM +0100, Eduardo wrote:
> > of transactions per second. But because each transaction requires at
> > least two revolutions of the disk platter, SQLite is limited to about
>
> Why does a transaction commit require
On Mon, Jan 09, 2006 at 06:47:04PM +0100, Eduardo wrote:
> of transactions per second. But because each transaction requires at
> least two revolutions of the disk platter, SQLite is limited to about
Why does a transaction commit require two seperate writes?
--
Jim C. Nasby, Sr. Engineering
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
Alexander,
I like your general concept. Some years ago I implemented a somewhat
similar strategy in a product of ours which was SQLite-like in that it
linked into each application process and managed B-Trees. By
identifying read-only transactions and handling them in a simple manner
Hello!
I think, there is another way for high-concurrency SQLite-based systems.
**It is not entirely universal**, but I hope it may be used for
high-traffic web sites and similar kind of systems, where each individual
transaction (such as a page retrieval or a form submission) is very
short and
"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
> expert in SQLite or databases,
On Sat, Jan 07, 2006 at 12:33:08AM -0500, Shailesh N. Humbad 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
> expert in
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
expert in SQLite or databases, so I would appreciate any comments or
criticisms. Here
12 matches
Mail list logo
