Ann,

we do have lots of duplicates in foreign keys. I guess there is no
solid way out of it in FB 1.5

Most of our tables are updated only from time to time and the rest
of them only receive new records from INSERTs (traffic data that
comes continually).
There are two exceptions though: Two big tables also get SQL UPDATEs
besides INSERTs (one of them up to 5 updates per second, the other
not so "often"). Updated records are located using a primary key,
updated column(s) not indexed, nor FK restricted.
Does this add any garbage?

--
Also, could you please tell us which versions of FB do not suffer with
"very high-cpu loop removing duplicates from indexes if the duplicate
chain is longer than about 10000 records" ?

Thank you,
regards
Ferda

Ann W. Harrison wrote:

> Now as the the source of the problem. The normal cause of uneven poor
> performance is delayed garbage collection on indexes with large numbers
> of duplicates. Firebird changes the index code to avoid the problem,
> but earlier versions get into a very high-cpu loop removing duplicates
> from indexes if the duplicate chain is longer than about 10000 records.
>
>
> Have you checked for that? Gstat -a -r produces a report that includes
> the number of duplicates on a single value for each index (max dup).
>
>
> Regards,
>
>
> Ann