56.6. 토토 페이지 레이아웃

이 섹션에서는 사용된 페이지 형식에 대한 개요를 제공합니다. 이내PostgreSQL테이블 및 색인.[1]시퀀스 및토스트테이블이 포맷되었습니다 일반 테이블과 같습니다.

다음 설명에서 a바이트은 8비트를 포함하는 것으로 가정됩니다. 또한, 용어항목개별 데이터 값을 나타냅니다. 페이지에 저장됩니다. 테이블에서 항목은 행입니다. 인덱스에서는 항목은 색인 항목입니다.

모든 테이블과 색인은 배열로 저장됩니다.페이지고정된 크기(보통 8kB이지만 서버를 컴파일할 때 다른 페이지 크기를 선택할 수 있습니다. 테이블에서 모든 페이지는 논리적으로 동일하므로 특정 항목(행)은 모든 페이지에 저장될 수 있습니다. 인덱스에서는 첫 번째 페이지는 일반적으로 다음과 같이 예약되어 있습니다.메타페이지제어 정보를 보유하고 있으며 거기에 인덱스 내의 페이지 유형은 다음에 따라 달라질 수 있습니다. 인덱스 액세스 방법입니다.

표 56-2페이지의 전체 레이아웃을 보여줍니다. 각각 5개의 부분으로 구성되어 있습니다. 페이지.

각 페이지의 처음 24바이트는 페이지 헤더로 구성됩니다. (페이지헤더데이터). 그 형식은 다음에 자세히 설명되어 있습니다.표 56-3. 처음 두 필드는 다음과 관련된 가장 최근의 WAL 항목을 추적합니다. 이 페이지. 다음은 플래그 비트를 포함하는 2바이트 필드입니다. 이것은 그 뒤에 3개의 2바이트 정수 필드(pd_lower, pd_upper및pd_special). 여기에는 다음의 바이트 오프셋이 포함됩니다. 페이지 시작부터 할당되지 않은 공간의 시작 부분, 끝 부분까지 할당되지 않은 공간과 특수 공간의 시작 부분으로 이동합니다. 는 페이지 헤더의 다음 2바이트,pd_pagesize_version, 페이지 크기를 모두 저장합니다. 그리고 버전 표시기. 로 시작포스트그레SQL8.3 버전 번호는 4입니다.PostgreSQL8.1 및 8.2 사용됨 버전 번호 3;포스트그레SQL8.0 버전 번호 2를 사용했습니다.PostgreSQL7.3 및 7.4에서는 버전 번호를 사용했습니다. 1; 이전 릴리스에서는 버전 번호 0을 사용했습니다. (기본 페이지 레이아웃은 헤더 형식은 대부분의 버전에서 변경되지 않았지만 힙 행 헤더의 레이아웃은 다음과 같습니다.) 페이지 크기는 기본적으로 교차 점검으로만 존재합니다. 갖는 것에 대한 지원이 없습니다 설치 시 페이지 크기가 두 개 이상입니다. 마지막 필드는 페이지를 정리할 가능성이 있는지 여부를 보여주는 힌트 수익성: 페이지에서 정리되지 않은 가장 오래된 XMAX를 추적합니다.

모든 세부정보는 다음에서 찾을 수 있습니다.src/include/storage/bufpage.h.

페이지 헤더 다음에는 항목 식별자가 있습니다(ItemIdData), 각각 4바이트가 필요합니다. 아이템 식별자에는 항목 시작 부분에 대한 바이트 오프셋이 포함됩니다. 길이(바이트) 및 영향을 미치는 몇 가지 속성 비트 해석. 필요에 따라 새 항목 식별자가 할당됩니다. 할당되지 않은 공간의 시작. 항목 수 존재하는 식별자는 다음을 보고 확인할 수 있습니다.pd_lower, 새로운 할당을 위해 증가됨 식별자. 항목 식별자는 삭제될 때까지 절대 이동되지 않기 때문입니다. 해제되면 해당 인덱스를 장기적으로 참조하는 데 사용할 수 있습니다. 항목 자체가 페이지에서 다른 항목으로 이동되는 경우에도 컴팩트한 여유 공간. 실제로 항목에 대한 모든 포인터(아이템포인터, 일명CTID) 작성자:PostgreSQL페이지 번호와 항목 식별자의 색인입니다.

항목 자체는 뒤로 할당된 공간에 저장됩니다. 할당되지 않은 공간의 끝에서. 정확한 구조는 다양하다 테이블에 포함되는 내용에 따라 다릅니다. 테이블 및 시퀀스 둘 다라는 구조를 사용합니다.HeapTupleHeaderData, 아래에 설명되어 있습니다.

마지막 섹션은"특별한 섹션"액세스 방법이 무엇이든 포함될 수 있음 저장을 원합니다. 예를 들어, B-트리 인덱스는 다음에 대한 링크를 저장합니다. 페이지의 왼쪽 및 오른쪽 형제 및 기타 데이터 인덱스 구조와 관련이 있습니다. 일반 테이블은 특수 섹션 전혀(설정으로 표시됨)pd_special페이지 크기와 동일함).

모든 테이블 행은 동일한 방식으로 구성됩니다. 있다 고정 크기 헤더(대부분의 시스템에서 23바이트를 차지함), 그 뒤를 따릅니다. 선택적 null 비트맵, 선택적 개체 ID 필드 및 사용자 데이터. 헤더에 대한 자세한 내용은테이블 56-4. 실제 사용자 토토(행의 열)는 오프셋은로 표시됩니다.t_hoff, 항상 MAXALIGN 거리의 배수여야 합니다. 플랫폼. null 비트맵은 다음과 같은 경우에만 존재합니다.HEAP_HASNULL비트가 설정되었습니다t_infomask. 존재하는 경우 바로 시작됩니다. 고정 헤더 뒤에 1비트를 가질 만큼 충분한 바이트를 차지합니다. 데이터 열당(즉,t_natts비트 모두). 이 비트 목록에서 1비트는 다음을 나타냅니다. null이 아님, 0비트는 null입니다. 비트맵이 없으면 모든 열은 null이 아닌 것으로 간주됩니다. 객체 ID는 다음 경우에만 존재합니다.HEAP_HASOID비트가 설정되었습니다t_infomask. 존재하는 경우 직전에 나타납니다.t_hoff경계. 모든 패딩 만드는 데 필요함t_hoffa MAXALIGN null 비트맵과 개체 ID 사이에 여러 개가 나타납니다. (이것은 개체 ID가 적절하게 지정되었는지 확인합니다. 정렬되었습니다.)

모든 세부정보는 다음에서 찾을 수 있습니다.src/include/access/htup.h.

실제 데이터 해석은 정보를 통해서만 가능합니다. 대부분 다른 테이블에서 가져옴pg_attribute. 식별하는 데 필요한 핵심 가치 필드 위치는 다음과 같습니다.아틀렌그리고부착. 방법이 없습니다 특정 속성을 직접 가져옵니다. 단, 다음과 같은 경우는 예외입니다. 고정 너비 필드 및 null 값이 없습니다. 이 모든 속임수는 함수에 싸여 있습니다.heap_getattr, fastgetattr그리고heap_getsysattr.

데이터를 읽으려면 각 속성을 차례로 검사해야 합니다. 먼저 null에 따라 필드가 NULL인지 확인하십시오. 비트맵. 그렇다면 다음으로 이동하세요. 그런 다음 올바른 정렬. 필드가 고정 너비 필드인 경우 모든 바이트는 단순히 배치됩니다. 가변 길이 필드인 경우 (attlen = -1) 그러면 좀 더 복잡해집니다. 모두 가변 길이 데이터 유형은 공통 헤더 구조를 공유합니다.struct varlena, 총계 포함 저장된 값의 길이와 일부 플래그 비트. 에 따라 플래그, 데이터는 인라인이거나토스트테이블; 압축될 수도 있습니다(참조)섹션 56.2).