Hi
The advantage is, that we can initalize more resultsets, not have to
allocate memory and not have to query count(*) statements.
Please never use 'SELECT COUNT(*)', the performance of Postgres' count(*)
is horrible.
'explain analyze select count(*) from dbmail_messages' takes 600ms for
my 6
Hi,
> >A numrows() solution will be the quick way to a first version, but we may
> >discover that the performance is terrible and 'SELECT COUNT(*)' is needed.
[..]
> The advantage is, that we can initalize more resultsets, not have to
> allocate memory and not have to query count(*) statements.
P
*Aaron Stone wrote:
likely that libdbi is adding this functionality. More likely, it's just
faking it somehow by retrieving all of the rows, counting them, and
caching them with the hope that they'll be requested later on anyways.
A numrows() solution will be the quick way to a first version, b
Hi,
I have a problem with anyone ACLs: using mutt I can change to:
imaps://server/#Users/myuser/INBOX/mailbox
When I try to select the folder in Thunderbirds 'manage folder
subscriptions' the user isn't even listed. So 'anyone' ACLs seems to
work, but 'anyone' folders aren't listed if a client as
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To
Dominik Fässler <[EMAIL PROTECTED]> said:
>>I've read that 'select count(*)...' is faster only if you aren't then
>>selecting all of the rows two lines later, in which case there's no
>>benefit. Which is to say, there won't be any drawback to eliminating our
>>use of num_rows() style functions, ex
