>
>In Firebird, it's not the number of indexes, per se. Firebird is a lot
>smarter about putting indexes to multiple use so -- I agree with you --
>Paradox schemas that are blindly reconstructed in a Firebird database
>generally kill performance because you typically have a lot of redundant
>indexes. But some indexes you are simply better off without.
>
>But this particular case is a whole lot of low-selectivity indexes created
>for foreign keys (10 or 11 in the table, as I recall). Basically, if
>German insists on retaining them, he will just have to live with slow
>performance that will get worse as the table gets bigger. In selects, a
>custom plan might help; but for inserts those long dup chains are just
>going to keep growing.
>
>./heLen

Thanks a lot for your very clear explanation, Svein and Helen.

So I would then assume that because I (1) have a PK in every table
(integer) and (2) try and keep my tables as "narrow" as possible, and (3)
avoid FKs, I wouldn't encounter similar problems?

We have several DBs that are 200 MB +, with upwards of 250 000 records in
the main DB. We get EXCELLENT performance from FB 1.5 - the entire shift
close process, for example, which runs about 30 SPs and Queries, generates
export files, and prints a report, takes generally under 12 seconds on the
DB. At the same time, records can be (and often are) inserted into the main
table.

Regards

Tim


[Non-text portions of this message have been removed]