Paul J Stevens wrote:
Aaron Stone wrote:
Mikhail Ramendik <[EMAIL PROTECTED]> said:
Aaron Stone wrote:
I haven't read the patch over yet, but I think Paul has (?). Wasn't
there
a thread about Firebird and/or Outlook problems with this or another
patch? Let's make sure that all of those
Paul J Stevens wrote:
> Mikhail, where's the db_header_speedup patch?
I'll post a roundup of all my patches on my Web site today.
I just hope to make one more patch before that (fixing the SEARCH UID
bug). Then I'll put all my patches online together, so they would not be
scattered in the mail a
Just curious, but I'm wondering why you're joining to the messageblks
table as it doesn't appear to have any bearing on the query?
Why not:
SELECT DISTINCT physmessage.id, physmessage.messagesize,
messages.seen_flag, physmessage.internal_date
FROM dbmail_mailboxes mailboxes, dbmail_messages m
Paul J Stevens <[EMAIL PROTECTED]> said:
[huge snip]
> Same goes for the dbmysql and my own db_getmailbox patches although that
> last one requires an addition index on dbmail_messages to be effective.
Does is degrade performance without the index? If not, I think we can put
it in a gray area, an
Paul J Stevens <[EMAIL PROTECTED]> said:
> Aaron Stone wrote:
>> Mikhail Ramendik <[EMAIL PROTECTED]> said:
I haven't read the patch over yet, but I think Paul has (?). Wasn't there
a thread about Firebird and/or Outlook problems with this or another
patch? Let's make sure that all of
I'm going to brute-force by trying combinations until
I get the wanted results now, but I do not really feel
well with doing this as it might be wrong in corner-cases.
Well, I think I have mostly figured out the basics of the
new schema now. So I made a simple drop-in replacement select
statemen
Aaron Stone wrote:
Mikhail Ramendik <[EMAIL PROTECTED]> said:
Aaron Stone wrote:
I haven't read the patch over yet, but I think Paul has (?). Wasn't there
a thread about Firebird and/or Outlook problems with this or another
patch? Let's make sure that all of those are resolved.
My split-u
The following bug has been SUBMITTED.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=111
==
Reported By:boersmic
Assigned T
> I'm going to brute-force by trying combinations until
> I get the wanted results now, but I do not really feel
> well with doing this as it might be wrong in corner-cases.
Well, I think I have mostly figured out the basics of the
new schema now. So I made a simple drop-in replacement select
stat
On Fri, 2004-10-29 at 15:19, Magnus Sundberg wrote:
> What about placing all the headers in a RAM table type, dbmail
> builds this table at startup. The content in this table should
> only be something like
> messageblock_id, header_name, header_value
> I leave it to you to think out the inexing
As has been mentioned elsewhere in this mail discussion,
We want a robust solution without upgrading scripts. The
application should take care of speed improvements.
What about placing all the headers in a RAM table type, dbmail
builds this table at startup. The content in this table should
o
Mikhail Ramendik wrote:
Hello,
I have retested the performance impact of my icfetch_speedup and
db_header_speedup patches. (My previous tests were irrelevant because
logging caused the main overhead).
The dbmysql patch was applied; it's simple and obvious so who needs to
test it anyway...
Here
Hi all,
It's good to see so much development happening.
Now, I was given the task to setup a complete
dbmail environment to replace the old Imail system
we are currently running (Due to Imail licensing
changes).
So, I've set up dbmail 2.0.0 on a test box using
LMTP as delivery from postfix. This
Hi Aaron,
> >> > But I also have a simpler idea that will still speed things up. It
> >> > involves using a regexp SQL fulltext search. While it's definitely slow
> >> > compared to a changed storage (the db won't be able to use indexes),
> >> > it's still faster because it does not involve any pa
Hello,
I have some further ideas on _ic_fetch() speedup, both for the time when
we have is_header and, as I spent some more time thinking, for the
current situation as well.
But I'm afraid I can't code them :( Complicated work in C turned out to
be too much for me. I'm a casual programmer only (
Speaking soley about 2.0CVS-Current
There could be a minor glitch with the icfetch_speedup pertaining to
MySQL. I noticed this after about ten hours. Traffic light, dept. int.
mail server, 128 accounts. The error seems to occur when the
messageblocks on a multipart physmessage_id contains a b
Hi,
I've been working on another project that has huge tables that need to be
searched, (1-3GB) and on my searches I could initially cut the table down to
a smaller piece by using a temporary table, and then applying the remainder
search patterns to this. This resulted in HUGE speedups of the s
For PostgreSQL there is Tsearch2 [1], Oracle has built in full text
search as far as I know, what about MySQL? I think it would be better
to
use special functions if they are available.
[1] http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/
Don't forget openfts.
http://openfts.sf.net/
Aaron Stone wrote:
> > We could introduce is_header usage even in 2.0.x, because the field is
> > present in 2.0. But is a database upgrade script acceptable, even if it
> > only fills in an already-present field?
>
> I'd am very, very much against an upgrade script within a stable series.
> We s
Mikhail Ramendik <[EMAIL PROTECTED]> said:
> We could introduce is_header usage even in 2.0.x, because the field is
> present in 2.0. But is a database upgrade script acceptable, even if it
> only fills in an already-present field?
I'd am very, very much against an upgrade script within a stable
Aaron Stone wrote:
> >> > But I also have a simpler idea that will still speed things up. It
> >> > involves using a regexp SQL fulltext search. While it's definitely slow
> >> > compared to a changed storage (the db won't be able to use indexes),
> >> > it's still faster because it does not involv
Thomas Mueller wrote:
> > > But I also have a simpler idea that will still speed things up. It
> > > involves using a regexp SQL fulltext search. While it's definitely slow
> > > compared to a changed storage (the db won't be able to use indexes),
> > > it's still faster because it does not involv
[EMAIL PROTECTED] wrote:
> Make sure you have mysql query cachining disabled for the test. Was it?
I restarted mysqld between the tests. Besides, the fastest were actually
tested first. And between the two fastest ones and the slowest one, the
machine was rebooted.
So caching only worked within
23 matches
Mail list logo
