On Fri, Jan 27, 2012 at 3:49 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
* Lars Lindner <lars.lindner@gmail.com> [2012-01-26 09:40]:
> My point is mainly that the reason for choosing sqlite is gone and
> there is at least one DB backend that has much better concurrent write
> access.

Last I checked it looked like Liferea loaded list views by SELECTing
every possible candidate record individually in a separate query, one
by one, then checking the result with a show-or-not predicate function
written in C. For a 100,000-entries list there are 100,000 queries
returning one row each.

I donít think SQLite is to blame for the performance issues.

(*Please* tell me I got this totally wrong.)

Current implementation is similar to what you describe, but the worst
case - the 100,000 scan - happens only when using the search feature
in an asynchronous manner. This is an improvement about the previous
implementation (1.4) using views for two reasons:

1.) Searching can be cancelled now. Back then it was a synchronously
created ad hoc sqlite view. With a large item set you'd have to wait
some minutes for it to complete.

2.) On startup we don't need to create on view per search folder.
(complexity m*O(n))

When updating feeds only new items are run against the predicate
functions. So it is hopefully not to bad.