Parsing is definitely the issue. I wrote a very simple Python application to parse headers in my dbmail inbox - a run against 50 messages takes about 4 seconds on a very fast box, using standard Python libraries.

The question is, what's more important - message insertion or subsequent processing. My vote is that subsequent processing (each access by a web mail, pop or IMAP client) is more important since they are 1 plus n accesses to the data, whereas insertion is a one time thing.

In the short term a web mail client could use the 'seen' flag - parse the messages and write to its own tables to contain the header fields of interest, but, would be nice to see dbmail 2.0 do this on message insertion.

Then watch imap fly!

At 07:14 PM 9/24/2002 +0200, you wrote:
Honestly I don't think using "select <fieldlist>" or "select *" is a big
speed difference - it's more like the ultimate fine tuning. I think
dramatic results can be achieved by developing a table layout/imap logic
that minimizes the number of queries and the amount of parsing done by
the imap server.


On Tue, 2002-09-24 at 18:55, Ryan Butler wrote:
> On Tue, 2002-09-24 at 10:48, Sam Przyswa wrote:
>
> > >Unless your program is getting back the rows as name value pairs and picking > > through what gets sent back, you want to be specifying the columns and the order > > that they are to be sent back, not asking for everything and assuming that the
> > order and number of the fields is what you think might be there.
> >
> > Sure it's easiest to SELECT named fields as SELECT * and use raw[x] to get the > > value. Our main goal it's to speed up DBmail and any suggestions are welcome !
> >
>
> That is not the easiest method, because unless you're getting it as an
> associative array (name/val pairs, etc)  Then you have no idea if raw[4]
> is really what you expect on every installation (someone may have added
> a field they need to the table).  That is why the inserts and selects
> only ask for the columns they need in the order they need.  So that the
> underlying table can be changed and not botch the whole system.
>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail


Reply via email to