51장. 롤 토토 파일

데이터베이스 파일 롤 토토 형식에 대한 설명입니다.

이 섹션은 다음에서 사용되는 페이지 형식의 개요를 제공합니다.포스트그레SQL테이블과 인덱스. (인덱스 액세스 방법은 이 페이지 형식을 사용할 필요가 없습니다. 현재는 모든 인덱스 방법은 이 기본 형식을 사용하지만 데이터는 계속 유지됩니다. 인덱스 메타페이지는 일반적으로 항목 레이아웃 규칙을 따르지 않습니다. 정확합니다.) TOAST 테이블과 시퀀스는 다음과 같이 형식화됩니다. 일반 테이블.

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

표 51-1기본을 보여줍니다 롤 토토의 레이아웃. 각 롤 토토에는 5개의 부분이 있습니다.

각 페이지의 처음 20바이트는 페이지 헤더로 구성됩니다. (롤 토토헤더데이터). 그 형식은 다음에 자세히 설명되어 있습니다.표 51-2. 처음 두 개 필드는 WAL 관련 항목을 다룹니다. 다음은 3개 입니다 2바이트 정수 필드(pd_lower, pd_upper및pd_special). 이는 바이트 오프셋을 나타냅니다. 할당되지 않은 공간의 시작부터 할당되지 않은 공간의 끝까지, 그리고 특별한 공간의 시작으로.

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

특수 공간은 페이지 끝에 있는 영역입니다. 페이지 초기화 시 할당되며 정보를 포함합니다. 액세스 방법에 따라 다릅니다. 페이지의 마지막 2바이트 헤더,pd_pagesize_version, 저장 롤 토토 크기와 버전 표시기 모두. 로 시작PostgreSQL7.3 버전 숫자는 1입니다. 이전 릴리스에서는 버전 번호 0을 사용했습니다. (기본 페이지 레이아웃과 헤더 형식은 변경되지 않았지만 힙 행 헤더가 있습니다.) 페이지 크기는 기본적으로 다음과 같이 나타납니다. 교차 점검; 두 개 이상의 페이지를 지원하지 않습니다. 설치 크기.

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

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

마지막 섹션은"특별한 섹션"액세스 방법이 무엇이든 포함될 수 있습니다. 저장을 원합니다. 일반 테이블에서는 이것을 전혀 사용하지 않습니다. (설정으로 표시됨pd_special에 롤 토토 크기와 동일).

모든 테이블 행은 동일한 방식으로 구성됩니다. 있다 고정 크기 헤더(대부분의 시스템에서 23바이트를 차지함), 그 뒤를 따릅니다. 선택적 null 비트맵, 선택적 개체 ID 필드 및 사용자 데이터. 헤더에 대한 자세한 내용은표 51-3. 실제 사용자 데이터(행의 열)는 다음으로 표시된 오프셋에서 시작됩니다.t_hoff는 항상 플랫폼에 대한 MAXALIGN 거리의 배수입니다. 널 비트맵은 다음과 같은 경우에만 존재합니다.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) 다음을 사용하면 조금 더 복잡해집니다. 가변 길이 구조varattrib. 플래그에 따라 데이터는 인라인이거나 압축될 수 있습니다. 또는 다른 테이블(TOAST)에 있습니다.