| Subject | Re: [Firebird-Architect] Question about limits in fb 2.5 or 3.0 |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2009-02-05T18:50:33Z |
woodsmailbox wrote:
code never ran on a 16 bit processor, at the time the ods was designed
both RAM and disks were much smaller ... unbelievably smaller than they
are now. We couldn't imagine a reason to "waste" two bytes on every
page and record reference when they'd never be used.
The fact that a page number is 16 bits is built into a ton of
structures. Unfortunately, in some places it's interpreted as a
signed 16 bit value, so the max is 32K. One of those places is in
the code that handles page buffers in memory. The page buffer includes
a buffer header, so a 32-bit page size caused the system to crash
because the total buffer size rolled over into the negative zone.
That would be the easiest fix - allowing a 32K page would double the
possible index key length. In theory, a thorough clean-up of all the
code making page numbers unsigned plus changing runtime structures
to use 32bits for the size of things would keep the ods unchanged
and allow for 64K pages, doubling the key length again.
Changing to a 32-bit page number would be a significant change,
requiring a new major ODS number and all the unpleasantness of
handling two ods's at once - it can be done, but its hard.
Changing the maximum record size is also an ods change because
the record length is stored on disk.
Changing the sort key size doesn't make a lot of sense if the
record is still limited to 64K ... (oh dear, I'm still thinking
the old way where sort keys were the same size as the fields
they represent ... some people would say that's an American
trait, but in fact it's just lazy. Americans expect A and a to
sort near each other too.) (Or maybe American == lazy.) Well,
with the key expansion from real world collations, increasing
the sort key size might make sense. And that's all runtime
stuff, so it's just a SMOP - no compatibility issues.
Cheers,
Ann
> Hi, just wanted to know of any plans to remove the various limits inAs a sort of Firebird historian, I can say that although the Firebird
> fb 2.5 or 3.0. Couldn't find the info anywhere so I thought I'd just
> ask here. I'm referring specifically to the 64k table record size, 64k
> sort record size, 4k index record size. And just out of curiosity,
> since I don't know the internals of the engine -- is this just a 16bit
> legacy thing that just gotta get 32/64bit (ods change/compatibility
> breaking included), or is it deeper than that? Thanx.
>
code never ran on a 16 bit processor, at the time the ods was designed
both RAM and disks were much smaller ... unbelievably smaller than they
are now. We couldn't imagine a reason to "waste" two bytes on every
page and record reference when they'd never be used.
The fact that a page number is 16 bits is built into a ton of
structures. Unfortunately, in some places it's interpreted as a
signed 16 bit value, so the max is 32K. One of those places is in
the code that handles page buffers in memory. The page buffer includes
a buffer header, so a 32-bit page size caused the system to crash
because the total buffer size rolled over into the negative zone.
That would be the easiest fix - allowing a 32K page would double the
possible index key length. In theory, a thorough clean-up of all the
code making page numbers unsigned plus changing runtime structures
to use 32bits for the size of things would keep the ods unchanged
and allow for 64K pages, doubling the key length again.
Changing to a 32-bit page number would be a significant change,
requiring a new major ODS number and all the unpleasantness of
handling two ods's at once - it can be done, but its hard.
Changing the maximum record size is also an ods change because
the record length is stored on disk.
Changing the sort key size doesn't make a lot of sense if the
record is still limited to 64K ... (oh dear, I'm still thinking
the old way where sort keys were the same size as the fields
they represent ... some people would say that's an American
trait, but in fact it's just lazy. Americans expect A and a to
sort near each other too.) (Or maybe American == lazy.) Well,
with the key expansion from real world collations, increasing
the sort key size might make sense. And that's all runtime
stuff, so it's just a SMOP - no compatibility issues.
Cheers,
Ann