63.6. 데이터베이스 토토 핫 레이아웃

이 섹션은 내에서 사용 된 토토 핫 형식의 개요를 제공합니다.postgresql테이블 및 인덱스.[1]시퀀스 및토스트테이블은 일반 테이블처럼 형식화됩니다.

다음 설명에서 Abyte는 8 비트를 포함한다고 가정합니다. 또한 용어항목페이지에 저장된 개별 데이터 값을 나타냅니다. 테이블에서 항목은 행입니다. 색인에서 항목은 색인 항목입니다.

모든 테이블과 인덱스는 배열로 저장됩니다pages고정 크기 (일반적으로 8kb, 서버를 컴파일 할 때 다른 페이지 크기를 선택할 수 있지만). 테이블에서 모든 페이지는 논리적으로 동일하므로 특정 항목 (행)은 모든 페이지에 저장 될 수 있습니다. 인덱스에서 첫 번째 페이지는 일반적으로 A로 예약됩니다.전달제어 정보 보유, 인덱스 액세스 방법에 따라 인덱스 내에 다른 유형의 토토 핫가있을 수 있습니다.

표 63-2토토 핫의 전체 레이아웃이 표시됩니다. 각 토토 핫에는 5 개의 부분이 있습니다.

각 토토 핫의 첫 24 바이트는 토토 핫 헤더로 구성됩니다 (PageHeaderData). 형식은에 자세히 설명되어 있습니다.표 63-3. 첫 번째 필드는이 페이지와 관련된 최신 WAL 항목을 추적합니다. 두 번째 필드에는 페이지 체크섬이 포함되어 있습니다.데이터 체크섬활성화되었습니다. 다음은 플래그 비트를 포함하는 2 바이트 필드입니다. 다음과 같은 3 개의 2 바이트 정수 필드 (가 이어집니다.PD_LOWER, pd_upper및PD_SPECIAL). 여기에는 토토 핫에서 할당되지 않은 공간의 시작, 할당되지 않은 공간의 끝 및 특수 공간의 시작까지 바이트 오프셋이 포함되어 있습니다. 토토 핫 헤더의 다음 2 바이트,pd_pagesize_version, 토토 핫 크기와 버전 표시기를 모두 저장하십시오. 부터 시작PostgreSQL8.3 버전 번호는 4;postgresql8.1 및 8.2 중고 버전 번호 3;PostgreSQL8.0 중고 버전 번호 2;PostgreSQL7.3 및 7.4 중고 버전 번호 1; 사전 릴리스 사용 중고 버전 번호 0 (기본 토토 핫 레이아웃 및 헤더 형식은 대부분의 버전에서 변경되지 않았지만 힙 행 헤더의 레이아웃은 있습니다.) 토토 핫 크기는 기본적으로 크로스 확인으로만 존재합니다. 설치에 하나 이상의 토토 핫 크기를 갖는 것을 지원하지 않습니다. 마지막 필드는 토토 핫 가지 치기가 수익성이 있는지 여부를 보여주는 힌트입니다. 토토 핫에서 가장 오래된 Xmax를 추적합니다..

모든 세부 사항은에서 찾을 수 있습니다.src/include/storage/bufpage.h.

페이지 헤더 다음은 항목 식별자입니다 (itemiddata), 각각 4 바이트가 필요합니다. 항목 식별자는 항목의 시작에 대한 바이트 오프셋, 바이트의 길이 및 해석에 영향을 미치는 몇 가지 속성 비트를 포함합니다. 새로운 항목 식별자는 할당되지 않은 공간의 시작부터 필요에 따라 할당됩니다. 존재하는 항목 식별자의 수는보기를 통해 결정할 수 있습니다.PD_LOWER, 새로운 식별자를 할당하도록 증가합니다. 항목 식별자는 해제 될 때까지 이동하지 않기 때문에 항목 자체가 페이지에서 이동하는 경우에도 항목을 참조하기 위해 장기적으로 인덱스를 사용하여 색인을 사용하여 여유 공간을 소형화 할 수 있습니다. 사실, 항목에 대한 모든 포인터 (ItemPointer, 또한CTID) 생성PostgreSQL항목 식별자의 페이지 번호와 인덱스로 구성됩니다.

항목 자체는 할당되지 않은 공간 끝에서 뒤로 할당 된 공간에 저장됩니다. 정확한 구조는 테이블의 내용에 따라 다릅니다. 테이블과 시퀀스는 모두 이름이 지정된 구조를 사용합니다HeappupleHeaderData, 아래 설명.

마지막 섹션은입니다."특별 섹션"액세스 방법이 저장하려는 모든 것을 포함 할 수 있습니다. 예를 들어, B-Tree Index는 인덱스 구조와 관련된 다른 데이터뿐만 아니라 토토 핫의 왼쪽 및 오른쪽 형제에 대한 링크를 저장합니다. 일반 테이블은 특수 섹션을 전혀 사용하지 않습니다 (설정으로 표시PD_SPECIAL토토 핫 크기와 동일).

모든 테이블 행은 같은 방식으로 구성됩니다. 고정 크기 헤더 (대부분의 기계에 23 바이트를 차지함)가 있고 옵션 NULL 비트 맵, 옵션 객체 ID 필드 및 사용자 데이터가 있습니다. 헤더는에 자세히 설명되어 있습니다.표 63-4. 실제 사용자 데이터 (행의 열)는로 표시된 오프셋에서 시작됩니다.t_hoff, 이것은 항상 플랫폼의 최대 거리의 배수입니다. NULL 비트 맵은 만있는 경우에만 존재합니다.Heap_hasnull비트가 설정되었습니다T_INFOMASK. 그것이 존재하는 경우 고정 헤더 직후에 시작하여 데이터 열에 대해 하나의 비트를 가질 수있는 충분한 바이트를 차지합니다 (즉,t_natts비트 모두). 이 비트 목록에서 1 비트는 널을 나타내지 않으며 0 비트는 널입니다. 비트 맵이 존재하지 않으면 모든 열은 무일치하지 않은 것으로 가정합니다. 객체 ID는 만있는 경우에만 존재합니다.Heap_hasoid비트가 설정되었습니다T_INFOMASK. 존재한다면 직전에 나타납니다.t_hoff경계. 만들기 위해 필요한 모든 패딩t_hoffmaxalign 배수는 NULL 비트 맵과 객체 ID 사이에 나타납니다. (이것은 객체 ID가 적절하게 정렬되도록합니다.)

모든 세부 사항은에서 찾을 수 있습니다src/include/access/htup_details.h.

실제 데이터 해석은 다른 테이블에서 얻은 정보로만 수행 할 수 있습니다.pg_attribute. 필드 위치를 식별하는 데 필요한 주요 값은입니다.attlenandattalign. 고정 너비 필드 만 있고 널 값이없는 경우를 제외하고는 특정 속성을 직접 얻을 방법이 없습니다. 이 모든 속임수는 기능으로 마무리됩니다heap_getattr, FastgetAttrandheap_getsysattr.

데이터를 읽으려면 각 속성을 차례로 검사해야합니다. 먼저 널 비트 맵에 따라 필드가 무효인지 확인하십시오. 그렇다면 다음으로 이동하십시오. 그런 다음 올바른 정렬이 있는지 확인하십시오. 필드가 고정 너비 필드 인 경우 모든 바이트가 간단하게 배치됩니다. 가변 길이 필드 (attlen = -1)라면 조금 더 복잡합니다. 모든 가변 길이의 데이터 유형은 공통 헤더 구조를 공유합니다Struct Varlena, 여기에는 저장된 값의 총 길이와 일부 플래그 비트가 포함됩니다. 플래그에 따라 데이터는 인라인 또는 A 일 수 있습니다.토스트테이블; 압축 될 수 있습니다 (참조섹션 63.2).