On Thu, 2006-09-14 at 01:31 -0400, Morty wrote: > On Tue, Sep 12, 2006 at 08:39:12AM -0600, Jesse Norell wrote: > > That's most likely the order in which the database returns the > > message id's .. eg. see what something like "select message_idnr > > from dbmail_messages where mailbox_idnr = xxxx" returns, it's > > probably the order you're seeing. You can turn logging up to level > > 5 to see the exact queries being run. As Mark pointed out, I > > don't think they're required to be in any order, and as such they > > likely aren't sorted (which would slightly improve performance), > > though doing so would be easy. > > For a LIST command, the query is: > > SELECT pm.messagesize, msg.message_idnr, msg.status, msg.unique_id > FROM dbmail_messages msg, dbmail_physmessage pm WHERE msg.mailbox_idnr = '81' > AND msg.status < '2' AND msg.physmessage_id = pm.id order by status ASC > > Looks like they are sorted, but by status. So the sort performance > hit is already there, it's just sorting by something > counter-intuitive. > > The RFC may not specify order, but received order seems to be the > de-facto implementation choice. Probably because POP3 became popular > in the Unix mailspool world, where email is naturally in received > order.
No it doesn't specify order; but it _does_ require that message numbers remain immutable over the coarse of a session. Consider what happens if the command sequence goes: UIDL TOP 10 0 and message number 10 suddenly referred to a different message between UIDL and TOP. You can do one of: * put everything POP3 related within a single transaction * save all the uidl values by querying the database once * order using a sequence (like idnr) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
