i.e. allow minetestmapper to query the database for a list of
blocks in a specific range (corresponding to the requested geometry),
instead of always obtaining a full list off all blocks.
As postgresql is the only database which supports this efficiently,
this option is only effective for postgresql.
As tests using --sqlite-cacheworldrow showed a consistently
lower performance than without, this option was effectively
disabled. It is still recognised for compatibility, but
it may be removed some time in the future.
Added the option to bulk load and cache entire world rows at
a time when using sqlite. Caching is implemented in the
database class this time around.
Enabled using --sqlite-cacheworldrow on the command line.
This is essentially re-introduces the database access strategy
that was used originally, but as an option.
Currently, one block is read at a time from the database.
The original behavior was to read and cache one entire world
row at a time, irrespective of whether or not only a (small)
subsection of the world was being mapped.
Under some circumstances, in particular if the entire world is
mapped or a relatively large percentage of it (blocks-wise), the
bulk loading and caching may outperform the one-by-one strategy,
even though it usually loads many more blocks than are actually
needed.
It seems that leveldb won't benefit from any kind of caching or
bulk loading of blocks, so none was implemented.
Leveldb does compile now. Still not tested on a database :-(
Improved the database statistics (printed with --verbose).
