| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 5. 데이터 정의 | Fast Forward | Next |
모든 테이블에는 시스템에 의해 암묵적으로 정의된시스템 열이 몇 개 있습니다. 그 때문에, 시스템 열의 이름은 유저 정의열의 이름으로서 사용할 수 없습니다 (이러한 제한은 이름이 키워드인가와는 관계 없습니다. 즉, 이름을 인용부호로 둘러싸도 이 제한을 피할 수 없습니다). 시스템 열에 대해서는 그다지 의식할 필요는 없습니다. 이들이 존재한다는 것을 알고 있으면 충분합니다.
행의 오브젝트 식별자(오브젝트 ID)입니다. 이 열은WITH OIDS를 붙였을 경우와 동시에 default_with_oids가 설정되어 있을 경우에 작성됩니다. 이 열의 형태는 oid(열명과 같음)입니다. 이 형태에 대한 자세한 사항은 Section 8.12을 참조해 주십시요.
이 행을 포함한 테이블의 OID입니다.
이 열은 특히, 상속 계층으로부터의 선택 쿼리에서는 편리합니다(Section 5.8를 참조해 주십시요).
이 열이 없으면 어느 테이블에서 그 행이 왔는지 이해하기 어렵기 때문입니다.
tableoid는 테이블명을 얻기 위해서pg_class의oid열에 조인할 수 있습니다.
이 행 버전을 위해 삽입하는 트랜젝션의 식별 정보(트랜잭션 ID)입니다. (행의 버전이란, 행의 개별 상태입니다. 행이 업데이트될 때, 동일한 논리적 행에 대해 새로운 버전의 행이 작성됩니다).
삽입 트랜잭션 내의(0으로 시작됨) 커맨드 식별자입니다.
삭제 트랜잭션의 식별 정보(트랜잭션 ID)입니다. 삭제되어 있지 않은 행은 0입니다. 보이는 행 버전에서 이 열은 0이 아닌 경우가 있습니다. 이것은 보통, 삭제 트랜잭션이 아직 처리되어 않았거나 삭제 시도가 롤백(rollback) 된 것을 의미합니다.
삭제 트랜잭션내의 커맨드 식별자 또는 0입니다.
테이블 내에 있어서의, 행 버전의 물리적 위치를 나타냅니다. ctid 행 버전의 위치를 빠르게 찾아내기 위해서 사용할 수 있지만, 행의ctid는 각 시간마다 업데이트되거나 VACUUM FULL에 의해 이동됩니다. 따라서, ctid는 장시간 행 식별자로서 사용할 수 없습니다. 논리 행을 식별하기 위해서는 OID나 보다 나은 유저가 정의한 연속되는 번호를 사용해야 합니다.
OID는 32 비트수이며, 클러스터 전체에서 하나의 카운터입니다. 대규모나 장기간 사용하는 데이터베이스에서는 카운터가 겹쳐질 가능성이 있습니다. 그 때문에, 유일성을 확인하기 위한 단계를 거치지 않는 한, OID가 유일하다고 가정해서는 안됩니다. 만약 테이블 내의 행을 식별할 필요가 있다면, 순서 생성기를 사용할 것을 강력히 추천합니다. 그러나 OID도 몇가지 추가적인 주의를 기울이면 이와 같이 사용할 수 있습니다.
유일성 제한은 OID가 행을 분류하기 위해서 사용되는 테이블의 OID열에 작성되어야만 합니다. 이러한 유일성 제한(혹은 유일한 인덱스)이 존재하는 경우, 시스템은 기존 행에 일치하는 OID를 생성하지 않습니다. (물론, 이것은 테이블 행의 수가 232(40억)보다 적은 경우에 가능해집니다. 작업 성능을 고려하면, 실제로 행의 수는 그것보다 훨씬 적은 것이 좋을 것입니다. )
OID는 복수의 테이블에 대해 유일하다고 가정되지 않습니다. 데이터베이스 전체에서 식별자가 필요한 경우는 tableoid와 행 OID를 조합해 사용해 주십시요.
물론, 문제되는 테이블은 WITH OIDS를 사용해 작성되지 않으면 안됩니다. PostgreSQL 8.1에 관해서, WITHOUT OIDS는 디폴트입니다.
트랜잭션 식별자도 32 비트 양입니다. 장기간 사용하는 데이터베이스에서는 트랜잭션 ID가 겹쳐 질 가능성이 있습니다. 이는 적절한 보수 작업을 통해, 치명적인 문제가 되지 않습니다. 자세한 사항은 Chapter 22을 참조해 주십시요. 그러나 오랜 시간에 걸쳐 트랜잭션 ID의 유일성에 의존하는 것은 현명하지는 않습니다.
커맨드 식별자도 또한, 32 비트 양입니다. 이 때문에, 단일 트랜잭션 내의 커맨드 수에는 232(40억) 개까지라고 하는 제한이 발생합니다. 실제, 이 제한은 문제 되지 않습니다. 이것은SQL커맨드 수에 대한 제한이며, 처리되는 행 수에 대한 제한이 아닌 것을 주의하십시요.