Ann et al,

> 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.

The 32K page size is not an easy fix; it requires the same clean-up as a
64K page size.

Back in FB v1.0 when I was able to cajole Mike Nordell into working on
increasing the page size (until that time max page size was 8KB), he was
able to increase the 16KB without a hitch, but 32KB cause the engine to
fall over.

As I recall, the problem was that due to signed page size value, the
true max page size was 32K - 1 byte, not 32K!

Given that the v1.0 the code base was such a mess, that is was
unthinkable to trying to go through the code and make all the necessary
changes, and then test all possibilities. With all the code scrubbing
that was done since then, the task is now much more reasonable.

In fact, about a year ago, I checked-out the code and did a search for
"page_size/pagesize" and found that there were less then two dozen
references. So, I started working on making the changes (it is
something that I believe that the engine needs more and more) and that
it was something that I could manage. But I found that some of the
references were for internal engine/index tree pages, not just disk
pages and decided that I didn't know enough (or rather knew enough to be
very dangerous) and dropped the issue.

The change to a 64K page size can easily be reached (~1 man day of work)
but needs to be done by someone with a reasonable knowledgeable of the
engine internals.


Sean

P.S. If someone (WINK to: Dmitry, Alex, Vlad, Claudio and Adriano) wants
to make the changes and send me a Windows EXE, I am more than happy to
test (we have several databases > 30GB)