SQLite Clarification

On Monday 31 July 2006 13:14, Clif Flynt wrote: >   My current report generator builds an SQLite database on the fly from > the flat ASCII logs. Seems like this would be ideal to marry to the realtime audit event interface. You would set log_format = nolog, dispatcher = /sbin/your-dispatcher, and disp_qos = lossless to keep the audit system from writing to disk, send events to a program, and use blocking comminucation to do it. >   I'm using SQLite instead of mySQL or Postgres because it it's fast, > mature and robust and doesn't  require any database server (or dbadmin) > to run it. I've been looking at using it too. I read some issues that made me wonder if it was really suitable: http://www.sqlite.org/whentouse.html At the bottom it mentions that if something has the database open for read, then writing is blocked. And the issue about the journal using 256 bytes for event MB of data made me wonder also.

The database file is only locked for the duration of the write operation - not while the database is open. A write normally takes a few milliseconds, then the lock goes away. Why is 256 bytes of data for each 1MiB of database a problem? Is memory so short and databases so large that this might cause a problem? If it is, then increase the page size from the default 1K. The actually usage is 2 bits per page of data. So if pages are 32KiB bytes instead of 1KiB, a 1MiB database only needs 8 bytes of storage for the bitmap. -- D. Richard Hipp <drh(a)hwaci.com&gt;