Re: [sqlite] sqlite not sharing page cache across processes?

2004-03-22 Thread Mark D. Anderson
ven more vulnerable to NFS than it is already. I would not suggest mmap as the only solution; as with web servers, I would suggest the strategy as a configurable option. Also, even I would hesitate over suggesting mmap for writers, without a lot of experimentation. On Mon, 22 Mar 2004 14:56:35 -0500,

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-12 Thread Mark D. Anderson
Echoing some others' responses, particularly Darren's: 1. I don't see the rationale for putting much priority on multiple string encodings. After all, blobs still can't be stored natively :). UTF-16 adds extra complexity, because of embedded nulls, and because of its own need for a

Re: [sqlite] Concurrency Proposal

2004-04-14 Thread Mark D. Anderson
On Wed, 31 Mar 2004 12:15:36 +1000, [EMAIL PROTECTED] said: > G'day, > [snip of Ben's pseudo-code] Just to check my understanding: the suggestion here is to reduce reader-writer conflict windows by buffering of writes. The writer acquires a read lock at the start of the transaction, and

Re: [sqlite] Concurrency, MVCC

2004-04-14 Thread Mark D. Anderson
Wednesday, April 14, 2004, 1:16:54 AM, Andrew Piskorski wrote: > as far as I can tell, it seems to be describing a system with > the usual Oracle/PostgreSQL MVCC semantics, EXCEPT of course that > Currie proposes that each Write transaction must take a lock on the > database as a whole. Well, i

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Mark D. Anderson
On Wed, 14 Apr 2004 08:13:39 -0400, "D. Richard Hipp" <[EMAIL PROTECTED]> said: >* Support for atomic commits of multi-database transactions, > which gives you a limited kind of table-level locking, > assuming you are willing to put each table in a separate > database. and

Re: [sqlite] Concurrency, MVCC

2004-04-15 Thread Mark D. Anderson
On Thu, 15 Apr 2004 20:16:32 -0400, "Doug Currie" <[EMAIL PROTECTED]> said: > I used this design in a proprietary database in the late 1980s. The > only reason I didn't consider modifying SQLite this way up until now > is that I was anticipating BTree changes for 3.0, so I confined my > efforts

Re: [sqlite] row size limit

2004-04-18 Thread Mark D. Anderson
These disk access issues are why no database I know of actually stores large objects inline. It would be crazy to do so. mysql, postgres, and oracle all have support for blobs, and none of them store them inline. (btw, if you care about disk io performance for blobs, you can tune the fs

Re: [sqlite] CppSQLite

2004-04-23 Thread Mark D. Anderson
There is no copyright statement or license stated in the article or in the download. So it isn't clear what the legal status is of CppSQLite? -mda On Fri, 23 Apr 2004 14:56:45 +0100, "Rob Groves" <[EMAIL PROTECTED]> said: > For those that are interested, a new version of CppSQLite and >