williamvdw2004 wrote:

>I have a table with about 630 000 records. I do the following count
>query. select count(transactionkey) from account.
>
>

unless things have changed regarding this, ....

Select count(*) from account gives the same results as select
count(transactionKey) from account (given that transactionkey is the
primary key.

The results could only be different if the data element allowed nulls.
< the nulls would not be counted>

This doesn't answer your question, but in the future with different
columns, you could be getting, what appears to you, erroneous results
unless you are aware of this.

Subsequently, if memory serves, you might even get a slight boost in
performace using select count(*) instead because it needn't analyze the
data in trasnactionkey.

>This query takes about 30 seconds the first time and 3 seconds
>subsequently. Transactionkey (bigint) is defined as the pimarykey of
>the table I have also added a descending index to the transactionkey
>column, page size is 8192. If I change the query to count the rows
>in the backup table the same thing 30 seconds the first time and 3
>seconds subsequently. Is there anything I can do to speed this up
>(the first query?)
>
>

Why do you need the count? Keep in mind that FB/IB does not maintain
this value as does MS SQL and others. . If you maintain counts in
auxillary tables that give you a count based on your trasnaction, it
could also complicate your UI because you could have a lot of users
trying to update that same row in the same table simultaneously.