Helen Borrie wrote:

>
> Anyway, the good news is that Firebird 2 lets you store ridiculously wide
> indexes - up to the page size, minus 4, minus (I suppose) a few other bytes
> that are earmarked for page pointers.

I think that 1/4 page, which is pretty close to the current size for 1K
pages ... another reason not to use 1K pages. We may remove the limit
altogether, by taking advantage of the fact that Firebird doesn't
completely trust indexes and checks the input value against the stored
value even after an index hit.

And while we're chatting, here's the scoop on compound indexes - or how
to really pessimize the amount of data you can index. When building a
compound index, the engine first converts each segment to its "natural
key" - simple char strings for char, expanded char strings for char with
complex collations, double precision inverted for numbers, etc.. It then
truncates trailing spaces or zeros, depending on type, leaving the field
length a multiple of 4. A varchar (1) would be converted to char (1)
then blank filled to char (4). Then the engine starts building up the
key. It stores the first 4 bytes of the first segment, then a byte with
the segment number, then the next 4 bytes and the segment number, etc.
The added bytes avoid the confusion that suffix compression could
introduce.

Sample confusion from truncating spaces: a four segment key, each
segment char (20).

First record: f1 = 'together', f2 = 'we' f3 = 'will', f4 'connive'
Second record: f1 = 'to', f2 = 'get', f3 = 'her', f4 = 'we will connive'



Regards,


Ann