Thomas Mueller <[EMAIL PROTECTED]> said:
>> > 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
Hi,
> > 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 parsing, and uses th
Make sure you have mysql query cachining disabled for the test. Was it?
Xing
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 pa
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.
>
> This was with the C
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.
This was with the CVS HEAD version. My existing speedup was intended for
2
Aaron Stone wrote:
Mikhail Ramendik <[EMAIL PROTECTED]> said:
Matthew T. O'Connor wrote:
dbmail 2.0+dbmysql: 128
2.0+dbmysql+icfetch_speedup: 184
2.0+dbmysql+icfetch_speedup+db_header_speedup: 193
I'm still very skeptical of making changes to is_fetch in the 2.0.x
branch.
Mikhail Ramendik <[EMAIL PROTECTED]> said:
> Matthew T. O'Connor wrote:
>
>> >dbmail 2.0+dbmysql: 128
>> >2.0+dbmysql+icfetch_speedup: 184
>> >2.0+dbmysql+icfetch_speedup+db_header_speedup: 193
>
>> I'm still very skeptical of making changes to is_fetch in the 2.0.x
>> branch. I'm all for putt
Matthew T. O'Connor wrote:
> >dbmail 2.0+dbmysql: 128
> >2.0+dbmysql+icfetch_speedup: 184
> >2.0+dbmysql+icfetch_speedup+db_header_speedup: 193
> I'm still very skeptical of making changes to is_fetch in the 2.0.x
> branch. I'm all for putting these in 2.1. Anyone else have any
> thoughts on
Mikhail Ramendik wrote:
Here are the results, on the same machine and the same settings, with no
other tasks running and no swapping, average between 10 secs somewhere
in the beginning of the operation and 10 secs somewhere at the end, in
messages per second:
dbmail 2.0+dbmysql: 128
2.0+dbmys
Bernard Johnson wrote:
> > Alternatively just search that file for "db_real_query", because that's
> > the call where it does the <0 check, and change the check there to !=0 .
>
> I had already grep'ed around and found that. I can manage the patch
> myself. Of particular concern is their statem
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 are the results, on the s
On Thu, 28 Oct 2004 19:32:32 +0400, Mikhail Ramendik wrote:
> This needs a change in dbmysql.c , in exactly one place. Do you want a
> patch against the original dbmysql.c, or against the dbmysql.c with my
> speedup patch (which was posted here some time before)?
>
> Alternatively just search that
Aaron Stone wrote:
> We should make this change in CVS for both HEAD and dbmail_2_0_branch and
> put a note on the website that 2.0.0 may have compatibility issues with
> MySQL 4.1.x.
Is there a cvs dbmail_2_0_branch already? If so, I'd really like to know
the decision on including my patches. Th
Mikhail Ramendik <[EMAIL PROTECTED]> said:
> Alternatively just search that file for "db_real_query", because that's
> the call where it does the <0 check, and change the check there to !=0 .
We should make this change in CVS for both HEAD and dbmail_2_0_branch and
put a note on the website that
Bernard Johnson wrote:
> Incompatible change: TIMESTAMP is now returned as a string in
> '-MM-DD HH:MM:SS' format (from 4.0.12 the --new option can be used to
> make a 4.0 server behave as 4.1 in this respect). See section 12.3.1.2
> TIMESTAMP Properties as of MySQL 4.1. If you want to have th
Seeing that mysql 4.1.7 is now "GA", I started looking into upgrading a
couple of servers. I took some time to read through the release notes
(http://dev.mysql.com/doc/mysql/en/Upgrading-from-4.0.html), and I found
two things that looked like they might cause some fits with dbmail 2.0.0.
Can some
Building the debian packages I noticed something else about the libs; All dbmail
libs and binaries are linked with the externally required libs.
For example; libdbmail, dbmail/libsort, dbmail/libauth, dbmail/libmysql are all
linked with the mysql client library. Same with the binaries.
This m
Sean Chittenden <[EMAIL PROTECTED]> said:
> Howdy. I'm the FreeBSD port maintainer for dbmail. To get dbmail to
> compile and install with libtool, it's necessary to specify the -fPIC
> option to gcc(1) when compiling the various object files. When libtool
> comes along and tries its magic,
Howdy. I'm the FreeBSD port maintainer for dbmail. To get dbmail to
compile and install with libtool, it's necessary to specify the -fPIC
option to gcc(1) when compiling the various object files. When libtool
comes along and tries its magic, it fails miserably on amd64. -fPIC
solves the pro
19 matches
Mail list logo
