# The directory that overview will be stored in is set in inn.conf with
# the 'pathoverview' option.  Other parameters for tuning ovsqlite are
# in this file.

# Compression: if INN was built with zlib support and this parameter
# is true, ovsqlite will compress overview records whenever this saves
# space.  This parameter is consulted only when creating a new database.
# Enabling compression saves about S<70 %> of disk space on typical
# overview data.
# The default value is false.
#compress:              false

# The maximum number of bytes of the database file that SQLite will
# memory-map.  When set, SQLite reads data via mmap instead of copying
# into its own page cache, which can improve read performance for large
# databases.  When WAL mode is enabled, nnrpd readers honor this setting
# too, which additionally lets them share physical memory pages for the
# same database regions through the operating system's page cache.
# This is of little benefit on ZFS or others without a unified buffer
# cache, where the mapped pages would be cached twice.
# A good value is the database file size or available memory, whichever is
# smaller.  Set to 0 (the default) to disable.
#mmapsize:              0

# WAL mode: if true, use SQLite's Write-Ahead Logging journal mode
# instead of the default PERSIST mode.  WAL mode allows concurrent
# readers and writers without blocking, improving read performance
# when multiple nnrpd processes access the overview database
# simultaneously.  Also sets synchronous to NORMAL, which is safe
# with WAL and reduces unnecessary fsync overhead.
# Note: WAL mode does not work on network filesystems such as NFS.
# The default value is false.
#walmode:               false

# The SQLite database page size in bytes.
# Must be a power of 2, minimum 512, maximum 65536.
# Appropriate values include the virtual memory page size and the
# filesystem allocation block size.
# This parameter is consulted only when creating a new database.
# The default value is left up to the SQLite library and varies
# between versions.
#pagesize:              4096

# The SQLite in-memory page cache size in kilobytes for the
# ovsqlite-server write daemon.
# The default value is left up to the SQLite library and seems to be
# stable at 2000 KB.
#cachesize:             2000

# The SQLite in-memory page cache size in kilobytes for each nnrpd
# reader process.  When WAL mode is enabled, nnrpd processes open the
# database directly for read-only access, bypassing ovsqlite-server.
# Each nnrpd process gets its own cache, so this value should be smaller
# or equal to cachesize.  The operating system's file cache (or ZFS
# ARC) serves as a shared second-level cache across all readers.
# The mmapsize parameter in this file can also be used to share
# physical memory pages across reader processes.
# The default value is 2000 KB (about 2 MB).
#readercachesize:       2000

# The WAL page count at which ovsqlite-server forces a checkpoint.
# When the WAL grows beyond this many pages, the server performs a
# TRUNCATE checkpoint during its next idle period, waiting up to
# 10 seconds for readers to finish their current queries before
# flushing WAL content back to the database file.  This prevents
# unbounded WAL growth.  If readers do not finish within the timeout,
# the checkpoint is skipped and retried on the next idle cycle.
# Only effective when walmode is enabled.
# The default value is 1000 pages.
#walcheckpointthreshold: 1000

# The maximum number of article rows that can be inserted or deleted
# in a single SQL transaction.
# The default value is 10000 articles.
#transrowlimit:         10000

# The maximum SQL transaction lifetime in seconds.
# The default value is 10 seconds.
#transtimelimit:        10.0

# A transaction occurs every transrowlimit articles or transtimelimit
# seconds, whichever is smaller.  You are encouraged to keep the default
# value for row limits and, instead, adjust the time limit according to
# how many articles your news server usually accepts per second during
# normal operation (you can find statistics about incoming articles in
# your daily Usenet reports).
# Inserting or deleting a database row within a transaction is very fast
# whereas committing a transaction is slow, especially on rotating
# storage.  Setting transaction limits too low leads to poor
# performance.  When rebuilding overview data, it may be worth
# temporarily raising these values on systems with slow CPU or rotating
# storage (for instance, multiply by 10 the default values).  Performance
# won't change much on fast systems.
