> create table test (
> id integer not null,
> column1 varchar(10) );
>
> alter table test add constraint pk_test primary key (id);
>
> create index idx_test on test(column1);
>
> insert into test values (1, 'test');
> insert into test values (2, 'test');
> insert into test values (3, 'test');
> insert into test values (4, 'test');
> insert into test values (5, 'test');
> commit;
>
> Statistics for the indices:
> pk_test - 0
> idx_test - 0
>
> FIRST QUESTION
> --------------
> When indices statistics are updated? Is it a manual process?
>
> set statistics index pk_test;
> set statistics index idx_test;
>
> Statistics for the indices:
> pk_test - 0,200000002980
> idx_test - 1

Yes. Indices are updatet either by
- SET STATISTICS ...
- or when index is activated (ALTER INDEX idx ACTIVE)
- or when index is created (e.g. as part of restoring from backup)

>
> select
> a.*
> from
> test a
> where
> a.id = 1
> order by
> a.column1
>
> Plan
> PLAN (A ORDER IDX_TEST)
>
> SECOND QUESTION
> ---------------
> Why the optimizer uses the index with lower selectivity in the case
> above, if in the where clause i'm searching the primary key?
>
> I'm having performance problems with tables with milion records, when
> i search in a column which has an index with high selectivity but the
> sort is made in a column which has an index with low selectivity.

The command will use both indexes, i.e. pk_test to find record, idx_test to sort result.
In FB1.5 and older, however, if the plan contains ORDER clause, it will not show
the index(es) used for searching.

Thanks to the way such command is executed internally, never use both indexes
for searching and ordering simultaneously for table with million or more records.

(and do not sort single-result-row queries :-)

Ivan