>>>>> "TR" == Thomas Raschbacher <firstname.lastname@example.org> writes:
TR> has anyone experience with users with lots of folders, where
TR> retrieving the folder list takes 5-10 seconds (tested with just
TR> a python interactive prompt, so it really only does that)
Unfortunately dbmail was written expecting only dumb sql servers, so it
does only simple queries. Listing the folders or opening one does *lots*
of queries, and the network latency adds up quickly.
About a decade ago now I posted some patches for using a CTE (aka with
clause) to use a single sql query when listing the groups. The patches
were postgres-spefic (what I use, and mysql didn't support CTEs at the
time), and so were ignored by upstream.
At the time they reduced the time it took to list my dbmail imap groups
from aroung 5 minutes to around 5 miliseconds. (Not counting the time
the mua needed to process the imap results.)
My patches for dbmail 2 are in the archives.
A similar change is required for opening a group.
It should take a single sql query to list all (or a subset) of a user's
groups. And it should take a single sql query to enter a group.
After that, only another single query should be needed to grab any given
message's messageblks. The rest of the metadata should have been grabbed
by the enter-group query. Then dbmail would be efficient.
But that only works with sql servers which support enough of ansi sql.
CTEs, in particular, are required for dbmail's schema.
James Cloos <email@example.com> OpenPGP: 0x997A9F17ED7DAEA6
DBmail mailing list