1) Since time of commit (3.0.0.31836, 15-May-2015) passed on only on SuperClassic. Failed on SuperServer. How could it be if test isn`t related to arch. specifics ?! Last letter to dimitr: 16-may-2015 13:55, subject: 'fix core-2078';

2) Representation of double precision values from rdb$indices.rdb$statistics differs on Linux vs Windows in 15th digit. Decided to change out-argument of procedure that does SET STATISTICS INDEX ... to numeric(12, 10);

3) Seems that some investigations should be in optimizer due to poor predictable PLAN when change initial values of rows number in tables.

### ACHTUNG ###
1) Since time of commit (3.0.0.31836, 15-May-2015) passed on only on SuperClassic. Failed on SuperServer. How could it be if test isn`t related to arch. specifics ?! Last letter to dimitr: 16-may-2015 13:55, subject: 'fix core-2078';
2) Representation of double precision values from rdb$indices.rdb$statistics differs on Linux vs Windows in 15th digit. Decided to change out-argument of procedure that does SET STATISTICS INDEX ... to numeric(12, 10);
3) Seems that some investigations should be in optimizer due to poor predictable PLAN when change initial values of rows number in tables.

The optimizer always had some trivial heuristics to estimate the effective stream selectivity even if no indices could be used for the retrieval. But this code hasn't been migrated into the new (post-ODS10) optimizer logic, thus causing ineffective join orders chosen for the cases when non-indexed predicates may noticeably truncate the leading stream output.

Description

The optimizer always had some trivial heuristics to estimate the effective stream selectivity even if no indices could be used for the retrieval. But this code hasn't been migrated into the new (post-ODS10) optimizer logic, thus causing ineffective join orders chosen for the cases when non-indexed predicates may noticeably truncate the leading stream output.