On Dienstag 09 Juni 2009 Aaron Stone wrote:
One concern I remember was about the running configuration
being different from the values in the database; basically, did you
manually alter the database config values without bouncing the
daemon?
A dbmail-config utility that managed this table for
On Montag 08 Juni 2009 Jonathan Feally wrote:
I'm not sure if a per user
script to move messages is the best approach. Probably just need to
add it to dbmail-util to move them from the old structure to the new
one. We don't even need to change the phymessage_id, just insert the
mimeparts,
Michael Monnerie wrote:
But how do you delete messageblks without their entire message? There
are lots of constraints all over the place. You'd need to redefine
those. OK, as there will be no more old inserts, it shouldn't really
hurt to loose those.
If per-user is not good - what would
Aaron Stone wrote:
We dropped the dbmail_config table very early on, between DBMail 1.1 and
1.2. There were good reasons to have a configuration file, and once things
started going in there, having two places to configure the daemons seemed
like a bad idea. One concern I remember was about
Jonathan Feally wrote:
The constraints are set such that the dbmail_phymessage row would need
to be deleted to cascade a delete in the dbmail_messageblks. So simply
inserting the unique parts in the mimeparts, then insert the part_id's
into partlists, update header cache, then delete the
Michael Monnerie wrote:
On Montag 08 Juni 2009 Jonathan Feally wrote:
I'm not sure if a per user
script to move messages is the best approach. Probably just need to
add it to dbmail-util to move them from the old structure to the new
one. We don't even need to change the phymessage_id, just
Paul J Stevens wrote:
Jon,
there's no need to update the header cache.
Ok, I wasn't sure. I didn't think it needed to be done. Throttling the
movement would be difficult. While the processing could be done on
another box separate of the production daemons, the database load and
disk
On Sonntag 07 Juni 2009 Jonathan Feally wrote:
Any DBA's out there want to chime in on using views vs. a query that
does it all in one? Performance, Best Practice, Pros/Cons??
I would definitely go for a full migration: If I upgrade to 2.4, I want
all the DB schema upgraded to 2.4, including
Michael Monnerie wrote:
Also, have a single upgrade script to upgrade any schema version to the
newest would be very appreciated. So people who have an early 2.2 would
also get the newset indices etc. A table version would be nice to have
where a single dbmail-schema value is included.
Since we are now using libzdb, we really only need to provide each
program with the connection string. It would dictate what database
type,
host, user/pass, db name, etc. That would make our dbmail.conf real
simple with just a connection string in it. Everything else would be
read from
On Mon, 8 Jun 2009 23:20:14 +0100, Jorge Bastos mysql.jo...@decimal.pt
wrote:
Since we are now using libzdb, we really only need to provide each
program with the connection string. It would dictate what database
type,
host, user/pass, db name, etc. That would make our dbmail.conf real
simple
Aaron Stone wrote:
We dropped the dbmail_config table very early on, between DBMail 1.1 and
1.2. There were good reasons to have a configuration file, and once things
started going in there, having two places to configure the daemons seemed
like a bad idea. One concern I remember was about the
Jonathan Feally wrote:
Paul,
You missed the DATE sort option.
Got it.
SORT has options for:
ARRIVAL (internal_date)
CC
DATE
FROM
SIZE
SUBJECT
TO
with the optional REVERSE tag in front to sort in opposite order.
All accounted for now.
I'm not sure it runs any faster with views than
Jonathan Feally wrote:
For the messageblks to mimeparts migration - I don't really care when it
is dropped. So 2.5 is a possibility. As long as 2.4 has a check if table
exists at daemon startup so that the code to read from that table is
completely skipped if absent. I think that once that
Paul J Stevens wrote:
What patch? I'm not sure I actually saw that one. Stripping out
execute_auto_ran would do the trick, right?
See attached patch.
-Jon
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
From
Jon,
I decided to try a different approach here. I just pushed out a change
that uses views to mimic the old tables (dbmail_subjectfield,
dbmail_tofield, dbmail_ccfield, dbmail_fromfield) that were used in
imap-sort. That allows me to stick to the join/order approach used in
dbmail-2.2 while
Paul,
You missed the DATE sort option.
SORT has options for:
ARRIVAL (internal_date)
CC
DATE
FROM
SIZE
SUBJECT
TO
with the optional REVERSE tag in front to sort in opposite order.
I'm not sure it runs any faster with views than with the larger query.
Since you are left joining the view, it does
I installed the latest code, fixed DB structure, rebuilt caches, and now
the IMAP search on text headers (subject, from, to) gives empty result.
BTW, during caches rebuilding the notices are written to the log:
Notice:[message] dbmail_message_cache_referencesfield(+1762):
reference_decode
What is the command line you/your client is issuing? I do not think that
it is a sort, as message-id is not one of the fields for sort that can
be used.
-Jon
Maxim Podorov wrote:
I installed the latest code, fixed DB structure, rebuilt caches, and now
the IMAP search on text headers
Jonathan Feally wrote:
What is the command line you/your client is issuing? I do not think that
it is a sort, as message-id is not one of the fields for sort that can
be used.
Still, the setup in dbmail-mailbox.c,_append_join_headervalue is broken
imo. That query should be reduced to
Paul J Stevens wrote:
Jonathan Feally wrote:
What is the command line you/your client is issuing? I do not think that
it is a sort, as message-id is not one of the fields for sort that can
be used.
Still, the setup in dbmail-mailbox.c,_append_join_headervalue is broken
imo. That
Jonathan Feally wrote:
In the IMAP SORT, we are trying to get all the message_idnr's in a
mailbox sorted by the criteria. 100% of the message_idnr's need to be
returned.
Nope. Sort supports all the same search criteria as IMAP SEARCH.
This leaves us with
SELECT message_idnr FROM
That's the yucky part, that is not needed.
I just pushed a cleanup that should at least put us back to where we
were before the headertable change in terms of correctness. There are
very likely still some issues with search as Michael reported, but
hopefully no new issues.
I had the sql
Jonathan Feally wrote:
The emailaddr column is used for sorting only. The headervalue column is
what is used for the where clauses.
Jon, in your latest code, the emailaddr/emailname columns are never used
again after insertion. We really shouldn't be storing information that
is not used,
Paul J Stevens wrote:
Jonathan Feally wrote:
The emailaddr column is used for sorting only. The headervalue column is
what is used for the where clauses.
Jon, in your latest code, the emailaddr/emailname columns are never used
again after insertion. We really shouldn't be storing
There is one more problem with new style of header caching.
These indexes are created:
CREATE INDEX dbmail_headervalue_2 ON dbmail_headervalue USING btree
(emailname);
CREATE INDEX dbmail_headervalue_3 ON dbmail_headervalue USING btree
(emailaddr);
But when I try to insert a message with extra
Sounds like we need to setup on the first x chars for indexing of those
columns. How many addresses were in the to: field? I'm not a postgres
guy, so I don't know how to do an index on the first x chars of the
field. From the error message below, it looks like we could use a size
of 2048.
Jon,
Similar indexes are present in the postgresql schema since 2.2.
For example in 2.2:
CREATE INDEX dbmail_headervalue_3 ON
dbmail_headervalue(substring(headervalue,0,255));
Jonathan Feally wrote:
Sounds like we need to setup on the first x chars for indexing of those
columns. How
On Donnerstag 28 Mai 2009 Maxim Podorov wrote:
CREATE INDEX dbmail_headervalue_2 ON dbmail_headervalue USING btree
(emailname);
CREATE INDEX dbmail_headervalue_3 ON dbmail_headervalue USING btree
(emailaddr);
We've had this issue in 2.2.x already. We could make an index of
The emailaddr column is used for sorting only. The headervalue column is
what is used for the where clauses. So the only column that needs to be
worried about for the index containing the data is the headervalue. In
most cases a 255 byte index on the emailaddr column would be sufficient
for
Paul, during IMAP search, SQLExceptions are thrown. The proposed fix is
below.
Best regards,
Maxim Podorov
--- dbmail-mailbox.c.orig 2009-05-18 09:45:15.0 +0400
+++ dbmail-mailbox.c 2009-05-21 13:09:28.0 +0400
@@ -1353,10 +1353,12 @@
g_string_printf(q,SELECT message_idnr
Looks like I missed that use of the datefield. I'll get a patch over to
paul for commit later on today. Your attempt will work for the time
being, but the joins need to be done a bit different for performance
reasons.
-Jon
Максим Подоров wrote:
Paul, during IMAP search, SQLExceptions are
32 matches
Mail list logo
