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]
