Ann et all,

Just to clarify...

The code provided in my original posting was an extract of "every"
location where "8196" or the appropriate/equivalent constant name was
source in the entire source. Yes, there are other locations where
page_size is referenced but in every case it is defined as a DWORD. So,
no real problems should be encountered.

Accordingly, it was to form the basis for someone to implement this
feature (I'm, unfortunately, not qualified for this task). Hence, the
reason I included the constant definition references ( "#define
MAX_PAGE_SIZE 8192") [I can, however, perform the necessary
research/review, with some assistance from others - nothing like making
work for other people ;-)]

With respect to your comments about Burp being tied to the engine.
While I appreciate that you see a problem with the current design. My
initial goal is to extend/enhance the functionality within the scope of
the existing design. I know that will run against your (let alone Jim's
;-) ) "architect" inclination and that one could argue that adding to a
back design is just poor work - but I think the community needs movement
as quick as it can be provided. Accordingly, I see this
review/correction as a post v1.0 task.

I also agree with you that 32Kb pages should be the new/intermediate max
page size. 64Kb pages - not just yet.


Sean


-----Original Message-----
From: Ann Harrison [mailto:aharrison@...]
Sent: Thursday, February 01, 2001 10:37 AM
To: Leyne, Sean
Cc: firebird-devel@...;
ib-architect@yahoogroups.com
Subject: Re: In for a penny in for a pound...

Sean,

I've taken the liberty of replying not only to you
but to the architecture and firebird developer lists
because this is a question that should interest both
of them.

>I'd like to suggest that we should also
>support page sizes of 16kb, 32Kb and 64Kb.
>

I agree with you about page sizes, but think that it
is something that should have a serious test. My inclination
is to make it one of the first new features after V1, unlike
the 64 bit I/O which should go in immediately. I'm also a
bit queasy about a 64Kb page size since a cache buffer is
a structure that includes a page (I think) and would therefore
be larger than 64K, breaking the allocator and a bunch of other
things that assume that a block length will fit in a short.

>As with anything, the use of
>these sizes it at the sysadmins discretion, all I'm doing is providing
>the "rope for them to hang themselves".

Right, but before it becomes a part of the product, I'd like to
have some idea of where the elephant traps are.

>Now as far as I can tell, adding this feature would not constitute or
>require an ODS change.

It would not be a major ODS change (unlike, for example, increasing
the size of an index key) but it may require a minor change (10.0 ->
10.1)
so that older versions of the product won't try to read it.

>Here's what I've found (after a painfull manual review of every module
>with the string "8192")
>
>[It would seem to have been an afterthought to have considated all of
>these settings into a single include file, each module has a different
>constant name]

There's some philosophical difference here. While I agree that within
a component (gbak, isql, ...) there should be a single include file,
I hesitate to insist on a single include file across components. Their
requirements are different and typically, one include file drags in
another, and so on. Suddenly something simple like gfix has all the
complex space management of the engine.

>***Burp\Burp.C
>...
> temp = tdgbl->gbl_sw_page_size;
> if (temp <= 1024)
> temp = 1024;
> else if (temp <= 2048)
> temp = 2048;
> else if (temp <= 4096)
> temp = 4096;
> else if (temp <= 8192)
> temp = 8192;

This particular little horror is my fault. At one time in
my life, I believed that software should smooth over little
errors that users make. Wrong. If the number entered is
not right, give an error and start training the user.

> else
>#ifdef SUPERSERVER
> BURP_svc_error (3, isc_arg_number, tdgbl->gbl_sw_page_size,
> 0, NULL, 0, NULL, 0, NULL, 0, NULL);
>#else
> BURP_error (3, (TEXT *) tdgbl->gbl_sw_page_size, 0, 0, 0, 0);

/*

>msg 3 Page size specified (%ld) greater than limit (8192 bytes) */
>#endif

This little horror, on the other hand, is not mine. The question
(one question) is why put conditional code around every single
error message rather than using a single message handler that has
conditional code within it to handle the messages appropriately
for the build type.

There's a larger horror here, in my opinion, which is the
integration of backup into the engine. Bad idea. Yes, it makes
backup faster, but the underlying problem is that local attachments
are slow. Find that problem and backup can return to being a
properly layered utility.

> if (temp != tdgbl->gbl_sw_page_size)
> {
> BURP_print (103, (TEXT *) tdgbl->gbl_sw_page_size, (TEXT

*)temp,

>0, 0, 0); /* msg 103 page size specified (%ld bytes) rounded up to %ld
>bytes */
> tdgbl->gbl_sw_page_size = temp;
> }
> }

This is the second half of my malfeasance. (Not to suggest that
this is my only malfeasance, just to acknowledge responsibility.

>**** Dudley\SQL.C

Dudley is the ancient ddl utility, and hasn't been
brought anywhere near modern standards. It was abandonned
when the native language for views, triggers, etc. changed
from GDML to SQL.

>static int par_page_size (void)
>{
>/**************************************
> *
> * p a r _ p a g e _ s i z e
> *
> **************************************
> *
> * Functional description
> * parse the page_size clause of a
> * create database statement
> *
> **************************************/
>int n1, n2;
>
>MATCH (KW_EQUALS);
>n2 = n1 = EXP_USHORT_ordinal (FALSE);
>
>if (n1 <= 1024)
> n2 = 1024;
>else if (n1 <= 2048)
> n2 = 2048;
>else if (n1 <= 4096)
> n2 = 4096;
>else if (n1 <= 8192)
> n2 = 8192;
>else
> SYNTAX_ERROR ("<page size> in range 1024 to 8096");
>ADVANCE_TOKEN;

Yes, those are my footprints.

>***Dudley/DDL.H
>
>#define MAX_PAGE_LEN 8192 /* max allowable length for a database
>page */

>***Jrd\ODS.H
>
>#define MAX_PAGE_SIZE 8192

Those seem straight forward.

>***Jrd\BTR.C (I'm not sure about this one...)
>
>#if (defined PC_PLATFORM && !defined NETWARE_386)
>#define OVERSIZE (dbb->dbb_page_size + BTN_SIZE + MAX_KEY +
>sizeof (SLONG) - 1)
>#else
>#define OVERSIZE (MAX_PAGE_SIZE + BTN_SIZE + MAX_KEY + sizeof
>(SLONG) - 1) / sizeof (SLONG)
>#endif

No, this is not a problem.

>***Jrd/DPM.E (I'm also not sure about this one...)
>
>#if (defined PC_PLATFORM && !defined NETWARE_386)
>UCHAR *temp_page = NULL;
>#else
>UCHAR temp_page[MAX_PAGE_SIZE];
>#endif

No issue here.

>***Remote\IBCONFIG.C
>
>// Fill the Map Size Combo Box
>SendDlgItemMessage(hDlg, IDC_MAPSIZE, CB_ADDSTRING, 0,(LPARAM)"1024");
>SendDlgItemMessage(hDlg, IDC_MAPSIZE, CB_ADDSTRING, 0,(LPARAM)"2048");
>SendDlgItemMessage(hDlg, IDC_MAPSIZE, CB_ADDSTRING, 0,(LPARAM)"4096");
>SendDlgItemMessage(hDlg, IDC_MAPSIZE, CB_ADDSTRING, 0,(LPARAM)"8192");

Fine. I suspect that there are other (many other) places where
page size is used, and most of them will float happily up to
32K


Regards,

Ann
www.ibphoenix.com
We have answers.