Thanks for the answer Claudio. Do have an idea, why a select on the
table
becomes more slowly after rebuilding the indices ?

Guido

"Claudio Valderrama C." wrote:

> <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.
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/