"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.
josé
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
