Helen Borrie wrote:

>At 09:35 AM 20/10/2005 +0000, you wrote:
>
>
>
>>>Back at you, to ask yourself why select count(*) is a "weakness" at
>>>all? What on earth do you want it for? It has its possible uses
>>>in aggregate queries, where it doesn't pose a performance problem,
>>>but what is a sensible reason for counting all of the rows in a
>>>table? And, if you do count them, which ones are you going to
>>>count? and why?
>>>
>>>
>>How about some OLAP-type queries:
>>- how many orders did we ship last month?
>>- how many customers have ordered widget X?
>>Or think about a web forum, displaying the number of reads, comments,
>>etc. for a specific article.
>>
>>
>
>Er-hum, none of those examples does a count(*) on a whole table.
>
>
>
>

Hi

I never said I meant a count of a whole table. What I meant was that
Count type queries are not recommended / slow in FB. This has been
attributed to the MGA in other discussions. However here I see that
many DBs have or are moving to MGA yet still have superior performance
in this area.

It seems to me it is FBs implementation that must be a bit weak in this
area (just like in other areas it is superior).

As for uses of count one of the most common ones I have is returning the
number of records a search is displaying. Just to append something like
'34 matches found' can dramatically reduce search time. However reading
Anns post it seems that FB 2 may have addressed some of the performance
issues :)

Looking forward to the release of FB 2 :)

Rob