[sqlite] Exclusive locking mode not working as expected?

I've been tearing my hair out over this for a little while, but I feel like there must be something simple I'm missing. Based on the behavior I'm seeing, the EXCLUSIVE locking mode isn't working the way I'd expect it to work based on the docs at

Re: [sqlite] LevelDB benchmark

With integer->blob mapping patch I get these results: $ ./db_bench_sqlite3 SQLite: version 3.7.7.1 Date: Fri Jul 29 05:32:05 2011 CPU:2 * Intel(R) Atom(TM) CPU N450 @ 1.66GHz CPUCache: 512 KB Keys: 16 bytes each Values: 100 bytes each Entries:100 RawSize:

Re: [sqlite] LevelDB benchmark

At 02:53 29/07/2011, Richard Hipp wrote: >On Thu, Jul 28, 2011 at 12:27 AM, wrote: > >I suspect that I will come up with other suggestions once I have a chance to >dig a little deeper into the benchmarks. If you have suggestions, please >publish them here. They are

Re: [sqlite] Exclusive locking mode not working as expected?

On 29 Jul 2011, at 07:49, Jonathan Little wrote: Hello, I am no expert in sqlite, but I do use it one of our projects. My interpretation of the documentation is slightly different to yours - see below > Specifically, that page says that locking_mode = EXCLUSIVE is useful > if "The

Re: [sqlite] Exclusive locking mode not working as expected?

On 29 Jul 2011, at 7:49am, Jonathan Little wrote: > Specifically, that page says that locking_mode = EXCLUSIVE is useful if "The > application wants to prevent other processes from accessing the database > file." However, if I start up a SQLite shell, set the locking_mode to > exclusive, and

Re: [sqlite] Exclusive locking mode not working as expected?

On Fri, Jul 29, 2011 at 10:49 AM, Jonathan Little wrote: > > This behavior seems undesirable to me -- we've got users of our application > copying the database file using Windows Explorer while it's being written > to, and ending up with inconsistent/corrupt databases. Am I

Re: [sqlite] LevelDB benchmark

What they don't say explicitly is that if all you need is key/value capability then an SQL database is overkill and only slows you down (bit of a duh factor there though not obvious to neophytes). Generally speaking that's one thing they don't teach in college is optimization. I can't count

Re: [sqlite] LevelDB benchmark

2011/7/29 Black, Michael (IS) : > What they don't say explicitly is that if all you need is key/value > capability then an SQL database is overkill and only slows you down (bit of a > duh factor there though not obvious to neophytes). The overhead by SQL layer is small.

Re: [sqlite] LevelDB benchmark

On Fri, Jul 29, 2011 at 12:30 AM, Alexey Pechnikov wrote: > With integer->blob mapping patch I get these results: > > Good information, Alexey. Thanks for running this. It would seem that the SQLite team has some serious work ahead of us. > > $ ./db_bench_sqlite3 >

Re: [sqlite] LevelDB benchmark

2X-20X is hardly "small...overhead" in my world. Even 2X is the difference between 30 days and 15 days. One 16-computer blade rack vs two racks ($200,000 vs $400,000). That's why google did this. Works for what they need and is lots cheaper. Michael D. Black Senior Scientist NG

Re: [sqlite] Exclusive locking mode not working as expected?

On Fri, Jul 29, 2011 at 11:08:19AM +0100, Simon Slavin scratched on the wall: > On 29 Jul 2011, at 7:49am, Jonathan Little wrote: > > > Specifically, that page says that locking_mode = EXCLUSIVE is useful > An exclusive lock will be retained only long enough to write changes > to the database

Re: [sqlite] LevelDB benchmark

At 14:19 29/07/2011, Black, Michael (IS) wrote: >What they don't say explicitly is that if all you need is key/value >capability then an SQL database is overkill and only slows you down >(bit of a duh factor there though not obvious to >neophytes). Generally speaking that's one thing they

Re: [sqlite] Exclusive locking mode not working as expected?

On Thu, Jul 28, 2011 at 11:49:34PM -0700, Jonathan Little scratched on the wall: > I've been tearing my hair out over this for a little while, but I feel > like there must be something simple I'm missing. Based on the behavior > I'm seeing, the EXCLUSIVE locking mode isn't working the way I'd >

Re: [sqlite] LevelDB benchmark

2011/7/29 Black, Michael (IS) : > 2X-20X is hardly "small...overhead" in my world. > > Even 2X is the difference between 30 days and 15 days.  One 16-computer blade > rack vs two racks ($200,000 vs $400,000). > > That's why google did this.  Works for what they need and is

Re: [sqlite] Exclusive locking mode not working as expected?

> Am I missing something here or if I want to prevent this, is my only option > to modify our build of SQLite to open the file for exclusive access? Yes, opening with exclusive access is the only option for you. But with latest SQLite version you don't have to modify SQLite sources for that. You

Re: [sqlite] Exclusive locking mode not working as expected?

On 7/29/2011 05:00, sqlite-users-requ...@sqlite.org wrote: > -- > > Date: Fri, 29 Jul 2011 10:41:59 +0100 > From: Kevin Martin > Subject: Re: [sqlite] Exclusive locking mode not working as expected? > > However, if I start up a SQLite shell, set the

Re: [sqlite] LevelDB benchmark

Dear Dr. Hipp, I'm a Product Manager here at Google and one of the authors of the benchmarks discussed on this thread. Our intention with the benchmarks was to compare LevelDB with popular storage engines for the specific use case for which it was built, mapping string keys to string values.

Re: [sqlite] LevelDB benchmark

Just a heads-up that we just posted an update to the benchmarks: - No more superfluous index on the primary key - WAL turned on with auto-checkpointing every 4096 pages http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html A diff of the results is here:

Re: [sqlite] LevelDB benchmark

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2011 02:45 PM, Gabor Cselle wrote: > (My understanding is that SQLite stores 64-bit, not 32-bit integers). SQLite actually stores integers using a variable length encoding and is documented here:

Re: [sqlite] LevelDB benchmark

On 07/30/2011 04:45 AM, Gabor Cselle wrote: > Just a heads-up that we just posted an update to the benchmarks: > - No more superfluous index on the primary key > - WAL turned on with auto-checkpointing every 4096 pages > > http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html > > A diff of

[sqlite] How to convert a database with FTS2 to FTS3/4?

sqlite newbie here. I have a sqlite3 database that was built using the FTS2 module. As such I get errors about the non-existent fts2 module when attempting to query the data. Is there a way to convert/migrate the data to FTS3 or somehow create an "alias" FTS2() call that just wraps around FTS3?