"Roger Binns" wrote...

On 22/09/14 10:48, Richard Hipp wrote:
But if you have any new ideas on how we can further reduce the I/O, we'd love to hear from you.

The single biggest problem for me is defaults.  SQLite supports memory
mapped i/o which has many advantages. The stat4 analyze does a really good
job.  WAL reduces writing contention.  These are all off by default for
various good reasons.  But it also means that by default the majority of
developers are not getting the best performance SQLite already has to offer,
unless they happen to stumble on these.  Some like stat4 are especially
problematic since it requires recompilation to address.

It would be nice if by default things were best. One weak suggestion is to have a few profiles, and have them selectable by pragma. The profile would then go ahead and set various options. Future versions of SQLite would also
then update the profiles.

For example:

 pragma profile='max_performance' -- turns on all above, ups caches etc
 pragma profile='min_memory'    -- tunes down everything related to memory

Various members of the SQLite consortium can then do things like:

 pragma profile='firefox'

This would be a nice set of options. On my case, I would set all connections to our project to be" max_performance", as it is what we need. Just thinking out loud.

sqlite-users mailing list

Reply via email to