> At 11:27 AM 6/10/03 +0200, Skopalik Slavomir wrote:
> >Hi,
> >My teoretical think:
> >Small linear index for fast acces (probably slow insert )
> >It is useful for small tables (aprox. 10 000 records, short PK like smallint).
> >This table is usualy static but much reading.
> >Acces to index by split interval algorithm.
> >Index will be contain sorted values and data pointers.
>
>
> Data values in the index are a real can of worms for a multi-generational
> database. To figure out what version you're looking at, the record version
> number must be written in the index node, meaning the index must be
> updated on every record update, including those in which the index is
> stable.
>
> Almost no gain, ever, and a huge, huge performance hit on updates.

In small static tables (like code lists) is focus on select not on modify.
Typical ration of select per update is greater then 10 000.
I think, that find value in linear index is cheaper then in B-Tree. Is it ?
This can't be default internal structure, it must be explicit specified.


By the way
(linear index can't help in this case)
My typical query is find first greater or first less then value.
I will happy if I can uses only one index.

Slavek