Re: sqlite3

[Lars Ingebrigtsen <larsi@gnus.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>                                sqlite  files  hash
>> Read/write value speed     ⚄       ⚅     ⚀
>> Read/write value mem       ⚅       ⚄     ⚀
>> List all values speed      ⚅       ⚀     ⚅
>> List all values mem        ⚃       ⚁     ⚃
>> Ease of moving around      ⚄       ⚀     ⚅
>
> I'm not 100% sure how to interpret (is a higher value for "mem" better
> or worse?), but it seems like, at least, for the original scenario of
> having large data sets sqlite might still be optimal.

⚅ is better than ⚄ etc.

> OK, but it's still the same number of writes, more or less?

Yup.  

> IO is the slow part of most programs, and when it comes to an SQL
> database, it might have to do an update in multiple places (e.g. the
> data and the index), rather than do one smooth write.
>
> Might also depend on the size of the write (how big the values are).

I think the main issue is probably that sqlite tries really hard to
maintain data integrity, so it does fsyncing etc.  (More or less
according to what pragmas you give it.)  It's nice in general, but
probably overkill for this use case.

> Speaking of the latter scheme, I might be missing some details, but
> sqlite should provide better atomicity guarantess in the same of being
> interrupted mid-write. Like, if we have one-file-per-value, then the
> total list of keys must live somewhere, and they can get
> desynchronized.

There is no total list of keys in multisession.el -- you define separate
objects that are each instantiated to disk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no