> - A related question, does Firebird store some runtime statistics as
> to which indexes have been used and how often?

No.

>
> - I know that to reduce the database size I need to do a backup and
> restore. That's already solved in my application. The issue I am
> dealing with is that I never ever delete any data stored in my
> database, so it grows continually backup or no backup. Obviously some
> old data is of little value and could be deleted, on the other hand
> it's not worth it to delete something if it only takes up a few
> kilobytes. I want to discover which tables to focus on, then find a
> way to delete old data from them.
>
> - The reason to reduce database size isn't the available disk space
> but the issue of backing up and replicating the data. While GBAK
> itself runs reasonably fast, I compress its output afterwards and
> that takes a long time (I use 7-zip for compression ratio, but it is
> offset by slow speed). Not to mention that it is very uncomfortable
> to transfer 70+ MB files over the internet, especially when I know
> that a significant portion of this amount is worthless data.

Firebird 2 will solve this problem with incremental backups. By all
means locate the culprit tables, but gbak + 7zip is pretty good.
Perhaps a replication solution is more appropriate to your needs than
to resend all the data every day?

An index on an integer type field is not going to be too bad (and the
index nodes aren't even in the backup so don't worry about them). An
index on a large varchar field may cause noticable database growth,
but again the only thing stored in the backup file is the instruction
to build an index on this field when restored.

Adam