Paul J Stevens wrote:
> > Paul seems to be more familiar with this area of code, so I'd prefer to
> > leave it to him to integrate your work on this.
>
> I my view the problem is not that the current query is slow. The
> core problem is that it's called too often.
Yeah, that too. :-) I figured it was being called because the current
state of the mailbox has to be returned by the IMAP server after each
command or something like that. Since you can have multiple
concurrent writers, there might not be a fast way of dealing with this
short of using triggers to manage a stats table or something, which
would rule out MySQL and SQLite as database engines, and thus rules
out that approach entirely.
> Kevin, I'd like a imap command sequence that triggers this problem
> so I can setup a testcase for 2.1. and start fixing this properly;
> move all mailbox code to dbmail-mailbox and do proper internal
> caching.
>From what I can tell, just doing a STORE of attributes is enough. I
can recreate the problem and email you the logs if you're interested.
Basically, any code path that calls db_getmailbox will fire off that
query.
> I hate complex adhoc solutions, and the current query is just too
> beautiful to discard.
If you say so. :-)
I rather dislike the current query myself. The GROUP BY solution, as
a query, seems to me to be much simpler and more elegant.
We don't have to create a single number as I did in the query, we can
return the actual flag values, thusly:
select seen_flag, recent_flag, count(*) from dbmail_messages WHERE
mailbox_idnr = '14' GROUP BY seen_flag, recent_flag
But that still won't get you any flag combinations that don't have
matching rows.
I'll see if I can work out a query that'll get us what we want
directly and more efficiently than the current query. Biggest problem
is that it has to work on MySQL and SQLite, too.
> What kind of gain do you think you can achieve here? 200%? That wont
> make this problem go away.
200% at a minimum. Quite possibly more. I haven't actually
implemented the change locally yet so I don't yet know just how much
better it will make things, but running the query by hand is quite a
lot faster.
> Just to be clear; If you do have an elegant, readable and
> maintainable solution I'm all for it.
Well, the *query* is utterly readable and maintainable. It just
requires a little more interpretation on the part of the code that
calls it, and then only because it doesn't return rows for all
possible combinations of the flags.
> Also, I'd like to hear more about your problems with mutt and
> tb. They work for me.
The latest problem I've had with 2.1.x-trunk is related to
dbmail-smtp. I use the mailbox2dbmail contrib script to populate
dbmail from my primary mail store and in the 2.1.x series the mail
server returns nothing when you attempt to retrieve a message. The
headers come back fine (after the case conversion fix), and the data's
in the database, but something about either the insertion of the
message or the retrieval of the message is busted. If I use
Thunderbird to copy the message from my primary IMAP server to the
DBMail server, the message is perfectly retrievable.
After that I dropped back to 2.0.7.
--
Kevin Brown [EMAIL PROTECTED]
