Dany,

> select c.ID , e.CD, f.CD, sum(a.STCK_CLC) as qty, e.UNT, d.ID, g.ID
> from t_in_ot2 a, t_in_ot1 b, M_FNGD c, M_ART d, M_Sz e, M_ASST f, M_CLR
> g, m_trs_typ h, G_TMP j
> where d.ID = c.ART_ID
> and   g.ID = c.CLR_ID -- (B)
> and   e.ID = c.SZ_ID
> and   f.ID = c.ASST_ID -- (A)
> and   c.id = a.id_gd
> and   b.id = a.id_in_ot1
> and   b.id_trs_typ = h.ID
> and   h.STCK_CLC is not NULL
> and   h.STCK_TYP = 'F'
> and   d.TYP = 'F'
> and   b.is_cls = 'F'
> and   b.trs_dt BETWEEN '12/31/11' and '09-18-17'
> and   b.id_div_lc = j.ID
> and   e.UNT in('PSG','CT')
> and   b.CHCK_BY is not null
> and   b.cncl_by is null
> and   a.IS_VW = 'Y'
> and   f.ID = c.ASST_ID -- DUPLICATE of (A)
> and   g.ID = c.CLR_ID -- DUPLICATE of (B)
> GROUP by c.ID, e.cd, f.cd, e.UNT, d.ID, g.ID


> Looks like FB 3.0.2 Query PLAN not as good as FB 2.5.2.
>
> How to make sure that Query PLAN from FB 3.0.2 is the optimum one? Bad
> plan affect performance badly.

It doesn't help that you have duplicate criteria specified, see above.

FYI, the query could be even faster with 2.5.x if you create some multi-segment indexes which had common criteria columns, as in:
index B ON t_in_ot1( id, is_cls, trs_dt, b.CHCK_BY)
index e ON M_Sz ( id, UNT)
index h ON m_trs_typ(id, STCK_TYP, STCK_CLC)


Sean