Select count(*) is slow
Reason is that Firebird doesn't keep information about number of records in database. Since query doesn't have WHERE clause, it cannot use index either, and has to go through all the records.
Keeping a count in a multiuser system is almost impossible as you would get different values for different transaction levels.
There are ways to get approximate count however:
You could add a table with two columns: a table name and record count, and then create triggers on all your tables (those you wish to track) to populate these. There might be problems with performance. Solution is to have a transaction table which only stores values +1 and -1, and to get the record count you just sum them up. Periodically, you would sum those up and insert as a single record, to keep the table small and fast.
There is another solution. This one is by Ivan Prenosil, a long time Interbase and Firebird hacker. This solution only returns an approximate record count. As Ann W. Harrison kindly explains: Any record that has had its primary key modified will appear twice if the old version has not been garbage collected and deleted records will continue in the count until they are garbage collected.
/* first update the statistics */
UPDATE RDB$INDICES SET RDB$STATISTICS = -1;
/* Display table names and record counts */
WHEN RDB$INDICES.RDB$STATISTICS = 0 THEN 0
ELSE CAST(1 / RDB$INDICES.RDB$STATISTICS AS INTEGER)
LEFT JOIN RDB$RELATION_CONSTRAINTS ON RDB$RELATIONS.RDB$RELATION_NAME = RDB$RELATION_CONSTRAINTS.RDB$RELATION_NAME AND RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
LEFT JOIN RDB$INDICES ON RDB$RELATION_CONSTRAINTS.RDB$INDEX_NAME = RDB$INDICES.RDB$INDEX_NAME
WHERE RDB$VIEW_BLR IS NULL AND RDB$RELATION_ID >= 128
ORDER BY 1;
This will only work on tables that have a primary key.