Re: db-backed mail back end

[Simon Josefsson <jas@extundo.com>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Pittman <daniel@rimspace.net> writes:
>
>> Gain?  For me, the biggest pain with Gnus right now is that there are
>> some scalability issues. I got sick of losing information that had been
>> on mailing lists, so I stopped expiring mail a couple of years ago.
>
> A db doesn't necessarily give you any performance gain.  If you're not
> careful with how you set things up, you can get arbitrarily awful db
> performance (and I should know, since I've been Oracling a lot these
> past years. :-))

I agree -- a db backend will most likely be slower than nnml.  NNML is
a datbase specialized for its purpose, a generic database will not be
faster.

...unless the backend interface design changes in the process, which
would make some speed improvements possible.

> If we were to design a mail back end that's supposed to scale to
> several hundred thousands of messages in thousands of groups -- how
> would we do that?  Perhaps somebody has pondered this question
> before.  :-)

Don't compute things that you don't need.  Entering a group should be
a call to `(switch-to-buffer (generate-new-buffer (format "*Summary
%s*" group))'.  Populating the view should be incremental and
asynchronous.  Threading should optionally be pushed down into the
backend (IMAP supports server-side threading, a database backend could
as well), with utility threading functionality in Gnus.  Etc.

Same goes for the group buffer, btw.  It should be displayed
immediately, and updating status on groups should happen
asynchronously.