Yes, very major.

Drew Northup, N1XIM


> -----Original Message-----
> From: Paul J Stevens [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 26, 2004 3:01 AM
> To: DBMAIL Developers Mailinglist
> Subject: Re: [Dbmail-dev] Two bottlenecks in db_getmailbox
> 
> 
> Drew,
> 
> Indeed, transactions are a recent addition to the codebase given 
> the required 
> support for non-transactional backends (myisam).
> 
> At present the needed calls are in place, but they are only used 
> by pipelined 
> insertion (dbmail-lmtp/dbmail-smtp).
> 
> A systematic rollout of transactional support is another major 
> speedup waiting 
> to happen.
> 
> 
> Drew Northup wrote:
> > What, you are using InnoDB tables without transactions?
> > 
> > Drew Northup, N1XIM
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Paul J Stevens [mailto:[EMAIL PROTECTED]
> >>Sent: Monday, October 25, 2004 4:18 PM
> >>To: Jesse Norell; DBMAIL Developers Mailinglist
> >>Subject: Re: [Dbmail-dev] Two bottlenecks in db_getmailbox
> >>
> >>
> >>
> >>Ok Jesse, thanks for the pointer.
> >>
> >>Looks like db_imap_append uses its own version of the insertion
> >>logic and still inserts messages with empty
> >>unique_ids during the insertion sequence. That should be fixed,
> >>if only be wrapping this in a transaction.
> >>Come to think of it, wouldn't transactions actually do?
> >>
> >>db_copymsg looks ok to me.
> >>
> >>
> >>Jesse Norell wrote:
> >>
> >>>>>And the second query changed to: [SELECT message_idnr, seen_flag,
> >>>>>recent_flag FROM dbmail_messages WHERE mailbox_idnr = '9' 
> AND status <
> >>>>>'2' AND length(unique_id) > 0 ORDER BY message_idnr ASC]
> >>>>
> >>>>unique_id!='' should go where not absolutely required.
> >>>>
> >>>>Any objections to removing that particular restraint from the code?
> >>>>
> >>>>I really don't know how that one ever got in. If anyone 
> happens to know,
> >>>
> >>>please speak or be silent for ever
> >>>
> >>>
> >>>>more :-) In my database there are no messages with an empty
> >>
> >>unique_id. And
> >>
> >>>there shouldn't be. Such sanity
> >>>
> >>>
> >>>>checks shouldn't hog the real-time performance, and be deferred to
> >>>
> >>>asynchronous maintenance like dbmail-util.
> >>>
> >>>
> >>>  Obviously from my last post, I'm not through my inbox yet...
> >>>As I mentioned, in at least one place in old (1.x) dbmail mail 
> insertion
> >>>(from memory, it seemed to be in the imap code, with a copy command
> >>>or somesuch) the status flag was not used to mark a message that
> >>>wasn't yet fully inserted (I think everywhere else the status was set
> >>>to 5 or something) - so everywhere that checked a message status also
> >>>got addended with an "AND unique_id != ''" clause and probably at some
> >>>later point someone looked at indexes in use and added unique_id to
> >>>a lot of them.
> >>>
> >>>
> >>>--
> >>>Jesse Norell
> >>>
> >>>[EMAIL PROTECTED] is not my email address;
> >>>change "administrator" to my first name.
> >>>--
> >>>
> >>>_______________________________________________
> >>>Dbmail-dev mailing list
> >>>Dbmail-dev@dbmail.org
> >>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>
> >>
> >>
> >>--
> >>   ________________________________________________________________
> >>   Paul Stevens                                  mailto:[EMAIL PROTECTED]
> >>   NET FACILITIES GROUP                     PGP: finger [EMAIL PROTECTED]
> >>   The Netherlands________________________________http://www.nfg.nl
> >>
> >>
> > 
> > 
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > 
> 
> -- 
>    ________________________________________________________________
>    Paul Stevens                                         [EMAIL PROTECTED]
>    NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
>    The Netherlands_______________________________________www.nfg.nl
> 
> 

Reply via email to