many thanks Ann for reply.
I´ve readed your techtext about indexes in ibphoenix, but still some
questions like anyone can see below...

> The next line says the tables has 178 data pages, and that
> the pointer page uses 178 slots - the second number would be
> higher if pages had been allocated and released after records
> were deleted. The average data page is 80% full, which is
> pretty good.
>
> > Data pages: 178, data page slots: 178, average fill: 80%

If I understand, if average is less (for example 20%) that mean a
table using many pages not filled with data (for example a huge delete
after a huge insert). In that case I can "correct" this runing a
backup'n'restore (what can act similar a "defrag in Window") or simple
let it be filling with dayly inserts (what can take some time in some
cases...). This mean this can or not cause slow down in DB. But
normaly will not. Right?

> The first index is the system generated index that maintains the
> primary key. It is index 0 for this table.

index 0 is first index created or mean that Select´s will try this
index first? or maybe both?

> > Index RDB$PRIMARY30 (0)
>
> The index depth is 2, meaning there is one top level page in
> the index, and some number of lower level pages. A leaf bucket
> is jargon for an index page on the lowest level, the level that
> points to records. There are 11 pages at the lowest level.
> An index node is an index entry - something that points to a
> record. This index has 8865 record entries, plus eleven entries
> at the next level up.
>
> > Depth: 2, leaf buckets: 11, nodes: 8865
>

so an index with Depth growing is bad. if I had a index in a table
with deph >= 5, I MUST do anything (like chage DB Pages Cache).

> The next line describes the next index on the table
> >
> > Index SAIDAPRODUTOS_IDX1 (1)
>
> The depth is still 2, but there are fewer pages used to hold
> the same number of entries, suggesting better compression.
> You would expect that if there are duplicate values because
> prefix compression totally removes the second and subsequent
> duplicate key values.
>
> > Depth: 2, leaf buckets: 10, nodes: 8865
>
> And indeed, the average data length is less than a third of
> a byte. Of the 8865 entries, there are only 599 distinct
> values (if I can subtract). One value is represented 39 times,
> which is the most instances of any particular value. In early
> versions of Falcon, long duplicate chains are a performance
> problem.
>
> > Average data length: 0.30, total dup: 6266, max dup: 38
> Good luck,
>
> Ann

ins´t 2599 distincts values (8865-6266=2599)?
so average data length can be calc by expr "(nodes-totaldup)/nodes"?
in this case? an bigger average data length is a "good" index and a
smaller a "bad" index that can slow down query?
that´s mean the first index is better than this second?


take too, for example the third index:

Index SAIDAPRODUTOS_IDX2 (2)
Depth: 2, leaf buckets: 9, nodes: 8865
Average data length: 0.02, total dup: 8740, max dup: 156

this index is in a DATE column. like you can imagine I use it in many
many querys. it have only 125 distincts values. one of this values is
repeated 156 times.
it this a bad index? can I drop this index?

This table is a with few inserts only for example, but understanding
this I wish I can do this in any table in any FDB.


Many Thanks again for anyone help