home *** CD-ROM | disk | FTP | other *** search
/ Complete Linux / Complete Linux.iso / docs / apps / database / postgres / postgre2.z / postgre2 / ref / files / page < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.3 KB  |  110 lines
  1. .\" XXX standard disclaimer belongs here....
  2. .\" $Header: /private/postgres/ref/files/RCS/page,v 1.7 1992/07/13 03:45:59 ptong Exp $
  3. .SP PAGE FILES 6/14/90
  4. .XA 1 "Page Structure"
  5. .uh NAME
  6. .sp
  7. \&.../data/... \*- database file default page format
  8. .uh DESCRIPTION
  9. .lp
  10. This section provides an overview of the page format used
  11. by \*(PP classes.
  12. Diagram 1 shows how pages in both normal \*(PP classes and
  13. \*(PP index classes (eg., a B-tree index) are structured.
  14. User-defined access methods need not use this page format.
  15. .lp
  16. In the following explanation, a
  17. .q byte
  18. is assumed
  19. to contain 8 bits.
  20. In addition, the term
  21. .q item
  22. refers
  23. to data which is stored in \*(PP classes.
  24. Diagram 1 shows a sample page layout.
  25. Running
  26. .q .../bin/dumpbpages
  27. or
  28. .q .../src/support/dumpbpages
  29. as the postgres superuser
  30. with the file paths associated with
  31. (heap or B-tree index) classes,
  32. .q .../data/base/<database-name>/<class-name>,
  33. will display the page structure used by the classes.
  34. Specifying the
  35. .q -r
  36. flag will cause the classes to be
  37. treated as heap classes and for more information to be displayed.
  38. .in -0.5i
  39. .(b
  40. .so ./files/page.tr
  41. .ce
  42. \fBDiagram 1:  Sample Page Layout\fP
  43. .)b
  44. .in +0.5i
  45. .lp
  46. The first 8 bytes of each page consists of a page header
  47. .r ( \c
  48. .b PageHeaderData ).
  49. Within the header, the first three 2-byte integer fields,
  50. .i lower,
  51. .i upper,
  52. and
  53. .i special,
  54. represent byte offsets to the start of unallocated space,
  55. to the end of unallocated space, and
  56. to the start of
  57. .q "special space."
  58. Special space is a region at the end of the page
  59. which is allocated at page initialization time
  60. and which contains information specific to an access method.
  61. The last 2 bytes of the page header,
  62. .i opaque,
  63. encode
  64. the page size and information on the internal fragmentation of the page.
  65. Page size is stored in each page because
  66. frames in the buffer pool may be subdivided into equal sized pages
  67. on a frame by frame basis within a class.
  68. The internal fragmentation information is used
  69. to aid in determining when page reorganization should occur.
  70. .lp
  71. Following the page header are
  72. item identifiers
  73. .r ( \c
  74. .b ItemIdData ).
  75. New item identifiers are allocated from the first four bytes of unallocated space.
  76. Because an item identifier is never moved until it is freed,
  77. its index may be used to indicate the location of an item on a page.
  78. In fact, every pointer to an item
  79. .r ( \c
  80. .b ItemPointer)
  81. created by \*(PP consists of a frame number
  82. and an index of an item identifier.
  83. An item identifier contains a byte-offset to the start of
  84. an item, its length in bytes, and a set of attribute bits
  85. which affect its interpretation.
  86. .lp
  87. The items, themselves, are stored in space allocated backwards
  88. from the end of unallocated space.
  89. Usually, the items are not interpreted.
  90. However when the item is too long to be placed on a single page
  91. or when fragmentation of the item is desired,
  92. the item is divided and each piece is
  93. handled as distinct items in the following manner.
  94. The first through the next to last piece are placed in an
  95. item continuation structure
  96. .r ( \c
  97. .b ItemContinuationData ).
  98. This structure contains
  99. .i itemPointerData
  100. which
  101. points to the next piece and the piece itself.
  102. The last piece is handled normally.
  103. .uh BUGS
  104. .lp
  105. The page format may change in the future to provide
  106. more efficient access to large objects.
  107. This section contains 
  108. insufficient detail to be of any assistance in writing a new
  109. access method.
  110.