Re: [sqlite] FTS & Doc Compression

While I am not directly concerned by the problem, a possibility to transparently compress the text of FTS3 tables (not the indexes, just the contents of the virtual column) using zlib would be great. I cut a database size in half by doing this on non-fts3 text tables. DEFLATE being very efficient

Re: [sqlite] game, set, match

On 4 Mar 2010, at 5:39am, P Kishor wrote: > My point was a bit different -- seems like > only SQLite offers the right mix of functional punch, agile > performance and lightweight footprint to be a viable technology for a > web database. I don't think any of those characteristics are the ones

Re: [sqlite] game, set, match

On Wed, Mar 3, 2010 at 11:16 PM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > P Kishor wrote: >> but we need >> multiple independent implementations to proceed along a >> standardisation path. > > They are right. Of course they are right. My

Re: [sqlite] game, set, match

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 P Kishor wrote: > but we need > multiple independent implementations to proceed along a > standardisation path. They are right. You couldn't even just reference SQLite as it does change with every release so it isn't 100% compatible with itself.

[sqlite] game, set, match

sqlite : 1, w3 : 0 "This specification has reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. Until another implementor is interested in implementing this spec, the

Re: [sqlite] Maximum database size?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Collin Capano wrote: > Why does it prefer to use > /var/tmp or some other temp directory as opposed to just using the > current directory? Is there some performance advantage in doing this? The temp tables are for a particular connection only. If

Re: [sqlite] Maximum database size?

Hi all, Thanks so much for the info! The problem does appear to have been due to temp_store_directory. It was set to /var/tmp; on our clusters /var/tmp exits on another disk which only has about 3GB free as opposed to the 3TB I have on the disk that the database lives on. I re-set it the

Re: [sqlite] FTS3 bug with MATCH plus OR

On Mar 3, 2010, at 6:26 PM, Ralf Junker wrote: > The recent changes to FTS3 fixed a long standing problem with MATCH > and > AND operators combined. Take this schema: > > drop table if exists myfts; > create virtual table myfts using fts3 (a); > insert into myfts values ('one'); > insert into

Re: [sqlite] FTS3 bug with MATCH plus OR

I can't speak to the question of whether it's a real problem, but I bet you can work around with a sub-select. Something like: select * from myfts where rowid = 1 OR rowid IN (select rowid from myfts where (myfts MATCH 'one')); -scott On Wed, Mar 3, 2010 at 3:26 AM, Ralf Junker

Re: [sqlite] Maximum database size?

On Wed, Mar 03, 2010 at 12:57:22AM -0500, Collin Capano scratched on the wall: > Hello SQLite users, > > I've been running into some disk I/O errors when doing things such as > vacuuming and/or inserting things into temp tables in a database. Both of those operations require temp space.

[sqlite] FTS3 bug with MATCH plus OR

The recent changes to FTS3 fixed a long standing problem with MATCH and AND operators combined. Take this schema: drop table if exists myfts; create virtual table myfts using fts3 (a); insert into myfts values ('one'); insert into myfts values ('two'); This following query produced an "unable

Re: [sqlite] Maximum database size?

On Mar 3, 2010, at 12:57 PM, Collin Capano wrote: > Hello SQLite users, > > I've been running into some disk I/O errors when doing things such as > vacuuming and/or inserting things into temp tables in a database. The > databases that are giving me trouble are quite large: between 29 and > 55GB.

Re: [sqlite] Maximum database size?

On Wed, Mar 3, 2010 at 8:57 AM, Collin Capano wrote: > The databases in question don't seem to be > corrupt; I can open them on the command line and in python programs > (using pysqlite) and can read triggers from them just fine. It's just > when I try to vacuum and

Re: [sqlite] Maximum database size?

On 3 Mar 2010, at 5:57am, Collin Capano wrote: > I've been running into some disk I/O errors when doing things such as > vacuuming and/or inserting things into temp tables in a database. The > databases that are giving me trouble are quite large: between 29 and > 55GB. However, as large as