First check whether the field is NULL according to the null bitmap. To read the data you need to examine each attribute in turn. All this trickery is wrapped up in the functions heap_getattr, fastgetattr and heap_getsysattr. There is no way to directly get a particular attribute, except when there are only fixed width fields and no null values. The key values needed to identify field locations are attlen and attalign. Interpreting the actual data can only be done with information obtained from other tables, mostly pg_attribute. Number of attributes, plus various flag bitsĪll the details can be found in src/include/access/htup_details.h. XID for VACUUM operation moving a row version Insert and/or delete CID stamp (overlays with t_xvac) (This in turn ensures that the object ID is suitably aligned.) Any padding needed to make t_hoff a MAXALIGN multiple will appear between the null bitmap and the object ID. If present, it appears just before the t_hoff boundary. The object ID is only present if the HEAP_HASOID_OLD bit is set in t_infomask. When the bitmap is not present, all columns are assumed not-null. In this list of bits, a 1 bit indicates not-null, a 0 bit is a null. If it is present it begins just after the fixed header and occupies enough bytes to have one bit per data column (that is, the number of bits that equals the attribute count in t_infomask2). The null bitmap is only present if the HEAP_HASNULL bit is set in t_infomask. The actual user data (columns of the row) begins at the offset indicated by t_hoff, which must always be a multiple of the MAXALIGN distance for the platform. There is a fixed-size header (occupying 23 bytes on most machines), followed by an optional null bitmap, an optional object ID field, and the user data. Ordinary tables do not use a special section at all (indicated by setting pd_special to equal the page size).įigure 73.1 illustrates how these parts are laid out in a page.Īll table rows are structured in the same way. For example, b-tree indexes store links to the page's left and right siblings, as well as some other data relevant to the index structure. The final section is the “ special section” which can contain anything the access method wishes to store. Tables and sequences both use a structure named HeapTupleHeaderData, described below. The exact structure varies depending on what the table is to contain. The items themselves are stored in space allocated backwards from the end of unallocated space. In fact, every pointer to an item ( ItemPointer, also known as CTID) created by PostgreSQL consists of a page number and the index of an item identifier. Because an item identifier is never moved until it is freed, its index can be used on a long-term basis to reference an item, even when the item itself is moved around on the page to compact free space. The number of item identifiers present can be determined by looking at pd_lower, which is increased to allocate a new identifier. New item identifiers are allocated as needed from the beginning of the unallocated space. An item identifier contains a byte-offset to the start of an item, its length in bytes, and a few attribute bits which affect its interpretation. Oldest unpruned XMAX on page, or zero if noneĪll the details can be found in src/include/storage/bufpage.h.įollowing the page header are item identifiers ( ItemIdData), each requiring four bytes. Page size and layout version number information LSN: next byte after last byte of WAL record for last change to this page The last field is a hint that shows whether pruning the page is likely to be profitable: it tracks the oldest un-pruned XMAX on the page. (The basic page layout and header format has not changed in most of these versions, but the layout of heap row headers has.) The page size is basically only present as a cross-check there is no support for having more than one page size in an installation. Beginning with PostgreSQL 8.3 the version number is 4 PostgreSQL 8.1 and 8.2 used version number 3 PostgreSQL 8.0 used version number 2 PostgreSQL 7.3 and 7.4 used version number 1 prior releases used version number 0. The next 2 bytes of the page header, pd_pagesize_version, store both the page size and a version indicator. These contain byte offsets from the page start to the start of unallocated space, to the end of unallocated space, and to the start of the special space. This is followed by three 2-byte integer fields ( pd_lower, pd_upper, and pd_special). Next is a 2-byte field containing flag bits. The second field contains the page checksum if data checksums are enabled. The first field tracks the most recent WAL entry related to this page. The first 24 bytes of each page consists of a page header ( PageHeaderData). New item identifiers are allocated from the start of this area, new items from the end. Contains general information about the page, including free space pointers.Īrray of item identifiers pointing to the actual items.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |