Ann,
thanks for explanation.

> (BITS_PER_LONG + 2);

....

> The extra two bits are free space indicators which are stored at
> the bottom of the pointer page - two bits per data page.

I assume it distinguishes [empty / full / half-empty] page.

> ... Firebird is assuming a zero length record.

....

> The actual minimum length record is two bytes - one
> byte for a single char field and one byte to hold the null flag,

And there can also be several padding bytes to ensure proper alignment
(e.g. shortest record_header+record+padding on win32 is 24 bytes,
i.e. 5 unused bytes assuming minimal length record)

> A more reasonable algorithm would use different values max_record
> values for different tables, taking a plausible compression ratio.
> Personally, I'd rather steal a couple bytes from the table portion
> of the db_key, though that's going to have repercussions everywhere.

Only very few people complained about too limited number of rows so far,
so enhancing the algorithm probaly does not have high priority
(especially considering it would require changing ODS);
OTOH, now if FB supports 64-bit I/O, more people will use it for large databases ...

Ivan
prenosil@...
http://www.volny.cz/iprenosil/interbase