ovsqlite

Julien ÉLIE julien at trigofacile.com
Sat Dec 19 23:14:33 UTC 2020


Hi Bo,

> 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:
   https://github.com/rra/rra-c-util/tree/master/m4
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 
think so)

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!

-- 
Julien ÉLIE

« Sol lucet omnibus. »


More information about the inn-workers mailing list