Hi all
I'm new in this mailing list. My job was/is to setup a mailserver with
postfix and a database backend. One of the condition is to use
Firebird as DBMS, so i decided to write another backend for dbmail.
If you not know Firebird, it's a open source database ported from
Interbase, wich suppo
Dominik Fässler <[EMAIL PROTECTED]> said:
>
> The main problem is, that Firebird's API not supports db_num_rows(),
> respectively only rows affected on INSERT, UPDATE and DELETE (not on
> SELECT). For this reason i correct all files, which contains
> db_num_rows() with db_fetch_row() statements. I
Aaron Stone wrote:
Is this in place of using a for loop? It would work, but there might be
some code where memory allocations or other logic occurs on the basis of
the number of rows that were found. Just keep an eye out for such things.
I've seen the code fragments, where memory allocation oc
Dominik Faessler <[EMAIL PROTECTED]> said:
> Aaron Stone wrote:
>
>>Is this in place of using a for loop? It would work, but there might be
>>some code where memory allocations or other logic occurs on the basis of
>>the number of rows that were found. Just keep an eye out for such things.
>>
> I
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, except gnarlier code in those places
:-\
Ok, I w
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
*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,
> >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
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
