julien at trigofacile.com
Sat Dec 19 23:14:33 UTC 2020
> All the actual code in ovsqlite-private.c should of course have
> #ifdef HAVE_SQLITE3 / #endif around it.
Added, thanks for the confirmation.
> I use a single compile-link-and-run test to probe for a sufficient
> version of SQLite. Feel free to refine this if you have more
> patience with autoconf than I.
I'll certainly integrate sqlite.m4 from rra-c-util:
and merge inside the specific test for HAVE_INTTYPES_H, PRIu64 and an
SQLite version >= 3.8.2.
I see that compression is disabled by default in ovsqlite.conf; is it
still nowadays the best configuration? (ovdb also disables it by
default but we may have a different behaviour, if better, for ovsqlite)
Commits are done by default after 10 000 transactions. Maybe a silly
question but how does ovsqlite behaves if INN (or better say
ovsqlite-server) crashes or is killed without exiting properly? (do we
loose up to 10 000 overview changes since last commit?)
With ovsqlite, are article counts in newsgroups always accurate? (I
I see that the removal of a newsgroup is deferred until the next
expiration, which is a good thing (preventing an error in a control
message or manually with ctlinnd).
In order to make searches faster (responses to HDR and XPAT when
requesting header fields stored in overview), wouldn't it be useful to
also store each header body (at least the mandatory ones in
overview.fmt) in a separate column? or would the gain be meaningless?
Thanks again for your very great work on ovsqlite!
« Sol lucet omnibus. »
More information about the inn-workers