Here is the analysis of the query:
-
explain analyze SELECT distinct ip FROM rawdata WHERE sid='2';
The selectivity of your qual is terrible. sid=2::SMALLINT is returning
half of the table as a potential match! It should be no surprise then
that the planner decided to do a sequenti
The search queries would be more intensive as it has to process each
record retrieved vs a just retrieving all the records.
The reason I have suggested the search block option is because in it's
current state, 2.0.1 + mysql, the BODY search is already useless, timing
out each time, so instead
I have a "bug" and a fix for the little import tool in the contrib
directory:
The bug:
craps out when dealing with mailbox names that contain spaces.
The fix:
79c79
< command = "%s -m %s -u %s" %(path,box,user)
---
> command = "%s -m \"%s\" -u %s" %(path,box,user)
whi
re: memcache
Great lead. Looks very exiting.
Glad you like it... it's amazing stuff. If you have any feature
requests for libmemcache(3) or pgmemcache, let me know... last I
checked I was in the good graces of the author. *grin* Seriously,
let
me know... memcached and pgmemcache would be
Sean Chittenden <[EMAIL PROTECTED]> said:
* Bug 118: dbmail-users -c username -W does not prompt for
password on FreeBSD.
[snip]
> mind, but it's probably a getopt cmd string problem as that's where
> most compatibility problems exist between Linux and anything not Linux.
In fac
* Bug 118: dbmail-users -c username -W does not prompt for
password on
FreeBSD.
Could this be related to bug 141? getopt on freebsd is behaving
different
from the linux implementation.
Nope, 141 was a null pointer (my fault). I have confirmed the getopt
behavior that I suspected from th
Paul J Stevens <[EMAIL PROTECTED]> said:
>> In my experience, there should always a be someplace for non-drastic
>> changes to go, otherwise you lose the feeling of motion on a project and
>> everything becomes this nebulous, "Oh, just wait for verion X.Y and we'll
>> have that feature."
>
> You
Paul J Stevens <[EMAIL PROTECTED]> said:
* Bug 97: all messages have RECENT flag in IMAP.
>>>
>>>This will not be fixed in 2.0 afaik. Doing this with even a small
>>>semblance of correctness will require some possibly fairly intrusive
>>>changes in imapcommands.c
>>
>> Seriously? This is
Aaron Stone wrote:
Paul J Stevens <[EMAIL PROTECTED]> said:
Aaron Stone wrote:
I just updated the 2.0 Status on the Wiki, and here's what's up:
Not yet in CVS, needs to be done before release
* Bug 97: all messages have RECENT flag in IMAP.
This will not be fixed in 2.0 afaik. Doing t
Aaron Stone wrote:
Matthew T. O'Connor said:
Paul J Stevens wrote:
Only clean and well tested fixes. No more butt-ugly hacks just for
performance sake.
Amen my brother! Please let the 2.0 branch not be a moving target!
Accecpt it's limitations and make the improvements in 2.1.
Are th
Aaron Stone wrote:
Matthew T. O'Connor said:
Amen my brother! Please let the 2.0 branch not be a moving target!
Accecpt it's limitations and make the improvements in 2.1.
Are there only bugfixes and new features, or is there a middle ground
where we improve and mature the applicatio
Matthew T. O'Connor said:
> Paul J Stevens wrote:
>>
>> Only clean and well tested fixes. No more butt-ugly hacks just for
>> performance sake.
>
> Amen my brother! Please let the 2.0 branch not be a moving target!
> Accecpt it's limitations and make the improvements in 2.1.
Are there only b
Ilja Booij <[EMAIL PROTECTED]> said:
> On Wed, 22 Dec 2004 09:22:44 +0100, Hans Kristian Rosbach wrote:
[snip]
>> What about adding a 3-min timeout on such caches? That way the admin can
>> be assured that any changes will propagate to currently active
>> connections within 3minutes.
This is exac
A BUGNOTE has been added to this bug.
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=125
==
Reported By:aaron
Assigned To:
Paul J Stevens wrote:
Known problems and bugs to be addressed in a future release
* Bug 125: Inefficiencies in ACL listing.
* Bug 133: Inefficiencies in Mailbox listing.
Only clean and well tested fixes. No more butt-ugly hacks just for
performance sake.
Amen my brother! Plea
Hi Hans,
> I have database with ~560.000 rows. One of the columns is an
> IP address (type:inet). Now, I want to only get the unique ip
> addresses out. That takes about 3minutes on a P4 2.66Ghz!
I don't know the PostgreSQL Code, I can only tell you from database
theory.
- a database uses an ind
Hi Paul,
> >* Bug 91: Infinite loops in both imapd and pop3d.
>
> I think the looping in the pop3 code was fixed already by you yourself. The
> imap loop is indeed a nasty and urgent matter. But reports have been slim
> lately regarding this issue
[..]
Your dbmail package from 1212 works l
Paul J Stevens <[EMAIL PROTECTED]> said:
>
> Aaron Stone wrote:
>> I just updated the 2.0 Status on the Wiki, and here's what's up:
>>
>> Not yet in CVS, needs to be done before release
>>
>> * Bug 97: all messages have RECENT flag in IMAP.
>
> This will not be fixed in 2.0 afaik. Doing th
Sean Chittenden <[EMAIL PROTECTED]> said:
>> re: memcache
>
>> Great lead. Looks very exiting.
>
> Glad you like it... it's amazing stuff. If you have any feature
> requests for libmemcache(3) or pgmemcache, let me know... last I
> checked I was in the good graces of the author. *grin* Seri
I am sorry for asking this here, but I thought it might
also benefit dbmail in the end.
I have database with ~560.000 rows. One of the columns is an
IP address (type:inet). Now, I want to only get the unique ip
addresses out. That takes about 3minutes on a P4 2.66Ghz!
Here is the analysis of the
re: memcache
Great lead. Looks very exiting.
Glad you like it... it's amazing stuff. If you have any feature
requests for libmemcache(3) or pgmemcache, let me know... last I
checked I was in the good graces of the author. *grin* Seriously, let
me know... memcached and pgmemcache would b
On Wed, 22 Dec 2004 09:22:44 +0100, Hans Kristian Rosbach
<[EMAIL PROTECTED]> wrote:
> > Question is, do we care? Would it be alright to only pull in new ACLs once
> > at the beginning of each IMAP session? If not, there isn't a whole lot of
> > optimization to be done, there's only two places wher
Sean,
Great lead. Looks very exiting.
Sean Chittenden wrote:
So I'm working on the ACL code, looking to reduce the number of queries
that are currently made. At the moment, every call to acl_has_right in
imapcommands.c results in a query. Ideally, we would only query the the
dbmail_acls table o
Aaron Stone wrote:
I just updated the 2.0 Status on the Wiki, and here's what's up:
Not yet in CVS, needs to be done before release
* Bug 97: all messages have RECENT flag in IMAP.
This will not be fixed in 2.0 afaik. Doing this with even a small semblance of
correctness will require s
Aaron Stone wrote:
""[EMAIL PROTECTED]"" <[EMAIL PROTECTED]> said:
Just want to add my take on this subject. It's related to the IMAP
access control but more in a global way and not on a per-user basis.
It would be real nice if there was a way to disable IMAP search
capability within dbma
> Question is, do we care? Would it be alright to only pull in new ACLs once
> at the beginning of each IMAP session? If not, there isn't a whole lot of
> optimization to be done, there's only two places where acl_has_right is
> called several times in succession within a funciton.
I think we shou
So I'm working on the ACL code, looking to reduce the number of queries
that are currently made. At the moment, every call to acl_has_right in
imapcommands.c results in a query. Ideally, we would only query the the
dbmail_acls table once, get all of the columns in one shot, and
remember
that.
R
So I'm working on the ACL code, looking to reduce the number of queries
that are currently made. At the moment, every call to acl_has_right in
imapcommands.c results in a query. Ideally, we would only query the the
dbmail_acls table once, get all of the columns in one shot, and remember
that.
Rig
28 matches
Mail list logo
