From: "Magnus Sundberg" <[EMAIL PROTECTED]>
> Matthew T. O'Connor wrote:
> > This is why I suggested the value pair design, since we won't always
> > know what's interesting.
> >
> Do you have any ideas of how to create an index, to get good
> request performance?
> something like
> CREATE TABLE in
From: "Jesse Norell" <[EMAIL PROTECTED]>
> > Right - we're working on the dynamic caching because with us being
> > too lazy to change dbmail to handle it itsself, that's the only
> > practical option available. The only reason to add that to the pop3/
> > imap daemons would be for seemless migr
On Tue, 2003-07-08 at 08:54, Matthew T. O'Connor wrote:
> I have no idea, unfortunately, I don't really know how the imap clients
> really work.
>
> My real question is what queries are being done by the server. When I
> use evolution and ask it to search the message body for a piece of text,
> Right - we're working on the dynamic caching because with us being
> too lazy to change dbmail to handle it itsself, that's the only
> practical option available. The only reason to add that to the pop3/
> imap daemons would be for seemless migration (all new messages get
> cached at injectio
> Along with "what queries are being done by the server," make sure
> we also look at whether these queries make sense. Ie. after looking
> at common requests for IMAP clients, can the current queries done by
> the server be improved upon?
Another thing I forgot to mention; along with optimiz
Hi,
Is it optimal to store each flag in a separate byte?
What about storing the flags as a bit in an int?
This is a little bit more troublesome to handle on the database
client side, but I think it offloads the server some.
But there might be some SQL queries that require access to the
flags
Matthew T. O'Connor wrote:
On Tue, 2003-07-08 at 11:18, Jesse Norell wrote:
One other thought; I'm not recommending the approach for splitting
message components (eg. file attachments) and saving as discrete
components, as I think the work involved and complexity introduced
may not be worth th
> I believe this is currently the inefficient copy-everything
> approach. If you move a message from one folder to another, I don't
> know what it does, it may just update the mailbox_idnr in the
> messages table entry. Search for shared folder discussions, as this
> is planned on being addres
> On Tue, 2003-07-08 at 11:18, Jesse Norell wrote:
> > One other thought; I'm not recommending the approach for splitting
> > message components (eg. file attachments) and saving as discrete
> > components, as I think the work involved and complexity introduced
> > may not be worth the benefits,
Matthew T. O'Connor wrote:
On Tue, 2003-07-08 at 06:44, Magnus Sundberg wrote:
Hi again,
I have done some more thinking about the database structure.
I am not sure of the performance gain with a fast header table
structure.
This would be ideal with a single table and one VARCHAR column
for ea
On Tue, 2003-07-08 at 11:18, Jesse Norell wrote:
> One other thought; I'm not recommending the approach for splitting
> message components (eg. file attachments) and saving as discrete
> components, as I think the work involved and complexity introduced
> may not be worth the benefits, but one of
> > This would be ideal with a single table and one VARCHAR column
> > for each _interesting_ header. How do we know what the clients
> > think are interesting headers?
>
> This is why I suggested the value pair design, since we won't always
> know what's interesting.
Yep. We need to be able
On Mon, 2003-07-07 at 12:59, Jesse Norell wrote:
> > My vision here is a "fastheaders" table which has a message number and
> > half a dozen columns defined. On some regular basis, or upon message
> > insertion, the messageblks table is scanned and the first entry of each
> > new message number, wh
On Tue, 2003-07-08 at 06:44, Magnus Sundberg wrote:
> Hi again,
> I have done some more thinking about the database structure.
> I am not sure of the performance gain with a fast header table
> structure.
> This would be ideal with a single table and one VARCHAR column
> for each _interesting_ he
Hi again,
I have done some more thinking about the database structure.
I am not sure of the performance gain with a fast header table
structure.
This would be ideal with a single table and one VARCHAR column
for each _interesting_ header. How do we know what the clients
think are interesting he
Hello again,
You know, you can turn on quite heavy logging for the mozilla
imap client.
This is just a short log from my surfing my inbox and sending a
small mail to myself (That is copied to the sent folder).
To get the imap commands use "grep SendData imaplog.txt"
I am sorry, but I can not
Hello,
I patched my imap server (uw :-() to log the requests from my
mail client (Mozilla 1.2.1).
/Magnus
The mozilla client generated the FETCH requests below
FETCH (FLAGS)
FETCH (FLAGS)
FETCH (UID RFC822.SIZE BODY[])
FETCH (UID RFC822.SIZE BODY[])
FETCH (UID RFC822.SIZE BODY[])
FETCH (BODYS
Hello,
(moving this to dbmail-dev)
> My vision here is a "fastheaders" table which has a message number and
> half a dozen columns defined. On some regular basis, or upon message
> insertion, the messageblks table is scanned and the first entry of each
> new message number, which is the header,
18 matches
Mail list logo
