Hi,

>
> This one has also many duplicates (75%) and when there are many

duplicates

> you should really ask the question to yourself if you need the

index.

>
> > Again, I think the optimizer should go to statistics and

determine

> > when to use an index and when not.
>
> Yes and it does on estimated values.
> I ask you before, did you run "SET STATISTICS INDEX <index-

name>" ? and is

> this on FB1.5 or FB1.5.1.
> There are thresholds for when a index will be used or not, so i'm

curious

> about your index-selectivity.
>

Yes, I run SET STATISTICS INDEX <idx> and these are the results.
What these staticics are?

IdxName Pos FldName FldId Stat
-------------------------------------------------------------------
RDB$PRIMARY69 0 TB_INSPECT_ID 9 0.000
TB_INSPECT_DATE_IDX 0 INSP_DATE 1 0.000
IDX_TB_INSPECT_WUP_DET2 0 WRITE_UP_DET2_ID 3 0.000
IDX_TB_INSPECT_WUP_DET 0 WRITE_UP_DET_ID 4 0.000
RDB$FOREIGN112 0 INSPECTION_GROUP_ID 7 0.000
IDX_TB_INSPECT_STATUS 0 STATUS 8 0.200
RDB$FOREIGN46 0 MACH_ID 5 1.000

I haven't run against FB1.5 yet. (I'm using my PC as a FB server to
separate databases because of the 100% CPU usage bug and...-Hope for
1.5.2) I'm not sure If I can setup a third PC to run FB1.5 :(


IDX_TB_INSPECT_WUP_DET2 and IDX_TB_INSPECT_WUP_DET can be removed
these indexes are intended to be used only with this query.
About the IDX_TB_INSPECT_STATUS I have a lot of queries that take
advantage of them. I should to evaulate it very well before removing
it.

Actually, the system is working "fast" because of the left joins (I
don't have not even one inner, or right join), the issue was the
optimization that FB does.