On Mon, 2005-03-14 at 21:35 +, Aaron Stone wrote:
> On Mon, Mar 14, 2005, Geo Carncross <[EMAIL PROTECTED]>
> said:
>
> > for I in ~/dbmail-archive/Maildir/new/*; do ./dbmail-smtp -f dbmail.conf
> > -d test -m INBOX < $I; done
>
> One message per second for two hours is 60 * 60 * 2 = 7200 mes
Thomas:
I just got done loading a shitload of messages. I'm seeing _exactly_ the
query plan I suspected, and I'm using the create_tables.sql from
branch_2.0 -- after adding indexes found in the create_tables.sql in
trunk, I noticed an insignificant speed change.
I've got 6000 messages here, and s
On MySQL:
4543 rows in set (0.28 sec)
41573 rows in set (1.69 sec)
So if this fixes it for Pg, then I think we've got a winner :-)
Aaron
On Mon, Mar 14, 2005, Geo Carncross <[EMAIL PROTECTED]>
said:
> Thomas:
>
> I just got done loading a shitload of messages. I'm seeing _exactly_ the
>
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=181
==
Reported By:Eduardo Stern
Assig
Geo Carncross wrote:
Injecting 6242 messages into dbmail-Pg (trunk) just took a little less
than TWO HOURS (using Syslog as a timer).
This is incredulous folks! If anyone's interested, I'll time it
accurately overnight (not waiting that long again!)
Geo, please consider that the trunk code
Hi Geo,
> I've got 6000 messages here, and subsecond queries; here's the EXACT
> query:
[..]
> Nested Loop (cost=0.00..46.85 rows=2 width=36)
Could you please always do an EXPLAIN ANALYZE? Your output only shows
what the planer expects without doing the query. With EXPLAIN ANALYZE
you get the
Hi Aaron,
> On MySQL:
>4543 rows in set (0.28 sec)
> 41573 rows in set (1.69 sec)
>
> So if this fixes it for Pg, then I think we've got a winner :-)
'in set' means 4543 results? Is there something like explain analyze in
MySQL too? Could you please post results?
0,04 ms per result in case
On Tue, 2005-03-15 at 09:23 +0100, Paul J Stevens wrote:
>
> Geo Carncross wrote:
> > Injecting 6242 messages into dbmail-Pg (trunk) just took a little less
> > than TWO HOURS (using Syslog as a timer).
> >
> > This is incredulous folks! If anyone's interested, I'll time it
> > accurately overnig
On Tue, 2005-03-15 at 13:49 +0100, Thomas Mueller wrote:
> I have 7.4.7 too. The results are MUCH better than what dbmail does at
> the moment so it's a real improvement. I don't know if it can be done
> better. The query on the mailbox with ~600 Mails (that's quite common I
> think) looses all its
On Tue, 2005-03-15 at 13:55 +0100, Thomas Mueller wrote:
> Hi Aaron,
>
> > On MySQL:
> >4543 rows in set (0.28 sec)
> > 41573 rows in set (1.69 sec)
> >
> > So if this fixes it for Pg, then I think we've got a winner :-)
>
> 'in set' means 4543 results? Is there something like explain anal
On Tue, Mar 15, 2005, Geo Carncross <[EMAIL PROTECTED]>
said:
> On Tue, 2005-03-15 at 13:55 +0100, Thomas Mueller wrote:
>> Could you please post results?
>> 0,04 ms per result in case of the 42k rows - that sounds like a
>> in-memory database.
>
> My entire dbmail db is only about 50M per 12k
Geo Carncross wrote:
> On Tue, 2005-03-15 at 13:49 +0100, Thomas Mueller wrote:
>
>>I have 7.4.7 too. The results are MUCH better than what dbmail does at
>>the moment so it's a real improvement. I don't know if it can be done
>>better. The query on the mailbox with ~600 Mails (that's quite common
On Tue, 2005-03-15 at 18:18 +0100, Thomas Mueller wrote:
> Geo Carncross wrote:
> > On Tue, 2005-03-15 at 13:49 +0100, Thomas Mueller wrote:
> >
> >>I have 7.4.7 too. The results are MUCH better than what dbmail does at
> >>the moment so it's a real improvement. I don't know if it can be done
> >>
13 matches
Mail list logo
