Record Length
All records contain the record length, a fixed-length portion which must be large enough to contain all the data (including keys) for a record, plus the overhead required to store a record on a data page.
See Record Overhead in Bytes Without Record Compression and Record Overhead in Bytes With Record Compression for how many bytes of overhead you must add to the logical record length to obtain a physical record length.
The following table lists the maximum record size for fixed length records.
1The page overhead and the record overhead are subtracted from the maximum page size to determine the maximum record size. The per record overhead is 2 bytes for each file format.
2System data requires an additional overhead of 8 bytes.
Note that the database engine turns on data compression for the file if the file uses system data and the record length exceeds the limit shown in the table above.
Optionally, the records in a file can contain a variable-length portion. A variable-length record has a fixed-length portion that is the same size in every record and a variable-length portion that can be a different size in each record. When you create a file that uses variablelength records, the fixed-length amount is the minimum length of each record; you do not define the maximum record length.
Theoretically, the maximum length of variable-length records is limited only by the transactional interface’s file size limit: 256 GB for Pervasive PSQL version 9.5 (128 GB for earlier 9.x versions and 64 GB for other earlier versions). In reality, the maximum is limited by such factors as the operating system and record access method you choose. If you retrieve, update, or insert whole records, then the data buffer length parameter, because it is a 16-bit unsigned integer, limits the record length to 65,535.
A data buffer is a transactional interface function parameter that you use to transfer various information depending on the operation being performed. A data buffer can contain all or part of a record, a file specification, and so forth. Refer to Table 15 in Chapter 5, Designing a Database for more information on data buffers.
*Note: The total bytes of data plus internal header information cannot exceed 64 KB (0x10000) bytes. The transactional interface reserves 1,024 (0x400) bytes for internal purposes, meaning you can have 64,512 (0xFC00) bytes of data.
If your file uses very large records, consider using variable-tail allocation tables (VATs) in the file. A VAT, which is implemented as a linked list, is an array of pointers to the variable-length portion of the record. VATs accelerate random access to portions of very large records. Some examples of very large records are binary large objects (BLOBs) and graphics.
For files that contain very large variable-length records, the transactional interface splits the record over many variable pages and connects the pages using a linked list called a variable tail. If an application uses chunk operations to access a part of a record and that part of the record begins at an offset well beyond the beginning of the record itself, the transactional interface may spend considerable time reading the variable-tail linked list to seek that offset. To limit such seek time, you can specify that the file use VATs. the transactional interface stores the VAT on variable pages. In a file containing a VAT, each record that has a variable-length portion has its own VAT.
The transactional interface uses VATs not only to accelerate random access, but also to limit the size of the compression buffer used during data compression. If your files use data compression, you may want to use VATs in the file.