<guido.klapperich@...> wrote in message
news:3B72DF96.FD6BBF1@......

> Next point: I have seen before deactivating and activating the indices,

the

> RDB$STATISTICS-column is 0,00 for all my indices and after rebuilding the
> indices all values are greater then 0,00. I don't know, what this mean,
> because I don't know what the column is for.

This column is basically the selectivity or the better said, the redundancy,
since it may be thought as the inverse of the selectivity. It's
1 / (count(distinct(column)))

FB doesn't compute this value on demand or after a threshold automatically.
When you force the index to be refreshed (inactive, active), it computes
such value according to the current information in the table.

Whether you see 0 or null in some system fields is a result of a subtle
interaction between DDL and DYN. DYN only stores fields that it's told to do
and if the field is nullable, the operation succeeds. The DDL code (part of
the DSQL facility) usually instructs DYN to store or change only the fields
needed by the operation. Since a new index by default is created active, DDL
doesn't include an op code to store something in this column, hence
rdb$index_inactive remains null that equates zero in this case. When you
alter the index to make it inactive, the operation is just to alter such
state, hence DDL has no other thing to do than telling DYN to set such value
to one. DYN will store 1=inactive. Next operation is to set the index active
again, hence DDL tells DYN to store zero.

C.