On Mon, 22 Mar 2004 14:35:23 -0500, "Doug Currie" <[EMAIL PROTECTED]> said:
> It has no way of knowing (save diffing the db) that "there have been
> no write transactions."
well, that should in principle be easy to accomplish, shouldn't it?
For example by having any writer increment a counter he
Mark D. Anderson wrote:
> Have you measured what improvement would be obtained by using readonly mmap()
> for readers, rather read()?
SQLite supports files that are larger than 4GB. I don't think
you can mmap() a file that big on a machine with a 32-bit
address space.
--
D. Richard Hipp -- [EMAIL
Monday, March 22, 2004, 1:46:00 PM, Mark wrote:
>> I have run experiments to see how much faster SQLite might
>> work if it didn't invalidate its cache so quickly. The
>> answer is about 15%. So it is probably worth looking into
>> someday. Note that such a change will be backwards but
>> not f
> I have run experiments to see how much faster SQLite might
> work if it didn't invalidate its cache so quickly. The
> answer is about 15%. So it is probably worth looking into
> someday. Note that such a change will be backwards but
> not forwards compatible. Suppose this change happened
> fo
Mark D. Anderson wrote:
My reading of the code has the readers flushing their cache often, and
not
using the journal at all to maintain consistency. My reading has the
reader start with nothing in the cache, lock the database with a read
lock, perform as many SQL queries as are in the single tex
> My reading of the code has the readers flushing their cache often, and
> not
> using the journal at all to maintain consistency. My reading has the
> reader start with nothing in the cache, lock the database with a read
> lock, perform as many SQL queries as are in the single text string it's
Mark,
"Mark D. Anderson" <[EMAIL PROTECTED]>
22/03/2004 05:15 AM
To: [EMAIL PROTECTED]
cc:
Subject:[sqlite] sqlite not sharing page cache across processes?
> It appears from looking at pager.c that every process working
> with a database acquires its o
7 matches
Mail list logo