Hello Matheus,

>
> > Generator values are stored on generator pages. In shared cache
> > architectures (i.e. SuperServer) a connection that changes a generator
> > value
> > gets a transient write lock on the page, makes its change and releases
> > the
> > page.
>
> This "page" is the mapping of a set of table records into a memory/disk
> page, right?
>

Right. Everything stored in the database, data, metadata, and structural
data, is stored on fixed sized pages. Pages come in different types: data,
blob, index, generator, page inventory, transaction inventory, header,
index root, and pointer. A generator page consists of a standard page
header (~20 bytes) plus an array of 64 bit integers. Every page in the
database is the same size, either 4, 8, or 16Kb.

>
> So, if I had a large number of generators, for workloads which accessed
> generators on different pages (say, generator ID 10 and generator ID 4000)
> there wouldn't be contention, right?
>

Depending on the page size, right.

>
> Is there a way of finding out how many pages are used to store a given
> table? Or documentation about how the mapping from tables to memory and
> disk pages are implemented on firebird?
>

Pretty simple. If you care about detail, look at ods.h for the size of the
PAG structure and the exact layout of a generator page. For a rough
approximation of the number of generators on a page, divide the page size by
8.

Note that this algorithm works ONLY for generators which are not normal
table data. Figuring out how many data records fit on a page is an advanced
exercise.

Good luck,


Ann


[Non-text portions of this message have been removed]