Subject | Re: [firebird-support] Problems with pages |
---|---|
Author | Ann W. Harrison |
Post date | 2004-11-22T19:12:32Z |
At 01:14 PM 11/22/2004, Uwe Grauer wrote:
certainly not there. My guess is that Alexey Kovyazin
has identified the problem. Although the record number
is a 32-bit quantity, the number space isn't dense, so
you can't actually store 2**32 records in a table.
The record number has three parts: the offset of the
record index on the page, the offset of the page number
on the pointer page, and the sequence number of the
pointer page. The record number is decomposed into its
component parts by:
1) determining the maximum number of record headers
and record index blocks that can fit on a page,
(962 on a 16K page)
2) dividing the record number by that value. The
remainder is the offset in the record index of
the record
3) determining the number of data pages that can be
stored on a pointer page (3847 on a 16k page).
4) dividing the result of step 2 by the value computed
in step 2. The remainder is the offset on the pointer
page of the data page.
5) using the result of step 4 as the sequence number of
the pointer page.
The largest possible value from step 5 for a 16K page is 1016,
so there can be at most 1016 pointer pages for any table using
a 16K pages size. That limits the total number of data pages
to 4,464,077. Smaller page sizes allow larger numbers of
pointer page, but since each pointer page represents fewer data
pages and each data page holds fewer records, the total number
of possible records is the same for all page sizes.
If you were actually storing empty records - records with no
columns defined - you'd get nearly 2**32 of them on those pages.
However, that case is rare. The larger the compressed record,
the fewer fit on a page, wasting part of the range of values.
For example, you can store only 140 records with a compressed
data length of 100 bytes on a 16K page, so you'd lose 822 potential
record per page. In fact, some of that space can be used for
back versions and record fragments, neither of which needs a
"real" record number.
Firebird2 corrects this problem by increasing the record number
size from 32 to 40 bits.
Regards,
Ann
> >Kinderbase is starting the and the problem is almost
>OK, Transactions should be started explicitly.
certainly not there. My guess is that Alexey Kovyazin
has identified the problem. Although the record number
is a 32-bit quantity, the number space isn't dense, so
you can't actually store 2**32 records in a table.
The record number has three parts: the offset of the
record index on the page, the offset of the page number
on the pointer page, and the sequence number of the
pointer page. The record number is decomposed into its
component parts by:
1) determining the maximum number of record headers
and record index blocks that can fit on a page,
(962 on a 16K page)
2) dividing the record number by that value. The
remainder is the offset in the record index of
the record
3) determining the number of data pages that can be
stored on a pointer page (3847 on a 16k page).
4) dividing the result of step 2 by the value computed
in step 2. The remainder is the offset on the pointer
page of the data page.
5) using the result of step 4 as the sequence number of
the pointer page.
The largest possible value from step 5 for a 16K page is 1016,
so there can be at most 1016 pointer pages for any table using
a 16K pages size. That limits the total number of data pages
to 4,464,077. Smaller page sizes allow larger numbers of
pointer page, but since each pointer page represents fewer data
pages and each data page holds fewer records, the total number
of possible records is the same for all page sizes.
If you were actually storing empty records - records with no
columns defined - you'd get nearly 2**32 of them on those pages.
However, that case is rare. The larger the compressed record,
the fewer fit on a page, wasting part of the range of values.
For example, you can store only 140 records with a compressed
data length of 100 bytes on a 16K page, so you'd lose 822 potential
record per page. In fact, some of that space can be used for
back versions and record fragments, neither of which needs a
"real" record number.
Firebird2 corrects this problem by increasing the record number
size from 32 to 40 bits.
Regards,
Ann