PostgreSQL Deep Internal

EXEM technical report no.012 Ver. 2
2016.10.20
PostgreSQL Deep Internal
(PostgreSQL 9.4)

Table of Agenda
02. PostgreSQL Architecture
01. PostgreSQL의 역사
03. PostgreSQL MVCC
04. Page Layout
05. Vacuum

© Copyrights 2001~2016, EXEM CO.,LTD. All Rights Reserved.
01. PostgreSQL의 역사

PostgreSQL Deep Internal01. PostgreSQL의 역사
PostgreSQL Core Team
Jolly Chen
Andrew Yu
Michael Stonebraker
The University of
California at Berkeley

Year Name Developer Features
1977-1985 Ingres
The University of
California at Berkeley
• Research prototype
• Relational Technologies
• Established the company Ingres in 1980
• Purchased by Computer Associates in 1994
1986-1994 Postgres Michael Stonebraker
• Research Prototype
• Spawned Illustra
• Purchased by Informix
1994-1995 Postgres95 Jolly Chen, Andrew Yu
• Added SQL
• Spawned PostgreSQL
1996- PostgreSQL(6.0)
• Renamed to PostgreSQL to reflect its support for
SQL
출처
• https://drive.google.com/folderview?id=0B4hWvkMs8fCPW
G44dDBITHpMc0U&usp=sharing_eid&ts=5702089b&tid=0B
4hWvkMs8fCPeU9oWEhHNnItVkk
• https://momjian.us/main/writings/pgsql/history.pdf

출처 http://www.slideshare.net/PGExperts/development-of-83-in-
india?qid=5218f563-3be2-41bc-b54d-9f3146df1f1f&v=&b=&from_search=1

Current (9.5)
2016-01-07
출처 get to know postgreSQL , Bruce Momjian

GreenPlum
HigoDB (China)
출처 원저자 Andy Mendelsohn
how oracle rule db world, Rich Niemiec

PostgreSQL Deep Internal02. PostgreSQL Architecture
Listener
Buffer cache
log buffer
DBWR LGWR

 Postgres server
Parse Traffic Cop Rewriter
Planner/
Optimizer
Executor
Symbol Tables, Data Tables, Libraries and so on. (Shared Repository)
Simple Query commands
Complex Query commands
Object
Definitions
Rule/View
Definitions
Statistics
User
Data
Data Rows/OutputClient Input(SQL)

Oracle PostgreSQL
Logical Physical Logical Physical
Database
Tablespaces
Segment
Extent
Oracle Block
Data file
Operating
System Block
DB cluster
DB Objects
8k pages
Tablespaces
Database
Data files
Operating
System Block
출처 http://www.p2d2.cz/files/postgres-for-oracle-dbas.pdf
 Oracle과 비교

Cluster
Users/
Groups
Databases
Schemas
Tables Views Sequences Synonyms Domains Functions
Tablespaces
 Database 구조
출처 http://ktdsoss.tistory.com/403

a
<Database Cluster>
base/
1/
(template0)
12891/
(template 1)
12896/
(postgres)
16384/
(sampledb)
16385/
(testdb)
global/ pg_xlog/
$PGDATA/
pg_clog/ pg_tblspc/
18740
(sampletbl)
Tablespace
database
subdirectories

Database Cluster
Sub
Directory
Configure
File
Lock
File
base per database subdirectories global
global cluster-wide information
pg_xlog transaction logs (WAL files)
pg_tblspc symbolic link to tablespace location
pg_clog transaction commit status data
pg_multixact multitransaction status data
pg_notify LISTEN/NOTIFY status data
pg_stat_tmp temporary file for statistics subsystem
pg_subtrans subtransaction data
pg_twophase state files for prepared transactions
postgresql.conf configuration parameter
pg_hba.conf host based access file
pg_ident.conf OS user mapping file
postmaster.pid
lock file with PID and shared memory
segment
postmaster.opts
command line options the server was last
started
 Database cluster
Parameter file
Online Redo

03. PostgreSQL MVCC

PostgreSQL Deep Internal03. PostgreSQL MVCC – 1) MVCC 정의 및 역사
Writing transactions does not prevent reading and vice versa,
because each one sees its own version of the database.
출처 https://en.wikipedia.org/wiki/Firebird_(database_server)#The_Multi-Generational_Architecture_.28MGA.29
MVCC (Multi Version Concurrency Control)

PostgreSQL Deep Internal03. PostgreSQL MVCC – 1) MVCC 정의 및 역사
• The Data Independence
• Set Processing
• High level language
1970년 E. F. Codd 박사의 논문
Traditional approaches to the synchronization problems of shared data accessed by concurrently
running computations have relied on mutual exclusion – the ability of one computation to stop the
execution of other other computations that might access or change shared data accessed by that
computation. Our approach is quite different. We regard an object that is modifiable as a sequence of
immutable versions. each version is the state of the object after an update is made to the object.
1978년 David Patric Reed 박사학위논문 MIT
1981년 PHILIP A. BERNSTEIN AND NATHAN GOODMAN 논문
• Multiversion Reading and Writing

출처 - Bernstein, Philip A.; Goodman, Nathan (1981). "Concurrency Control in Distributed Database Systems". ACM Computing Surveys.
03. PostgreSQL MVCC – 1) MVCC 정의 및 역사

1984년 Jim Starkey
• The first shipping, commercial database software product featuring
MVCC was Digital's VAX Rdb/ELN. The second was InterBase, both of
which are still active, commercial products.
• Firebird - Multi Generation Architecture (추기형 아키텍처)
1986년 Bob Miner
• 1986년 Oracle version 6 에서 Rollback Segment 도입
출처 - https://en.wikipedia.org/wiki/Multiversion_concurrency_control

1999년 Mikheev, Vadim B.
• 1999년 Vadim 이 PostgreSQL 6.5 에 MVCC 아키텍쳐를 도입함
출처 get to know postgreSQL , Bruce Momjian

PostgreSQL Deep Internal03. PostgreSQL MVCC – 2) MVCC에 대한 두 가지 접근법
• PostgreSQL, Firebird/Interbase, SQL Server 해당
• 데이터베이스에 다중 버전의 레코드를 저장
• 더 이상 필요하지 않을 때 모아둔 레코드를 버림
접근법 1
• Oracle, MySQL/InnoDB 해당
• 최신 버전의 데이터만 데이터베이스 내에 저장
• 언두를 이용하여 이전 버전의 데이터를 재구성
접근법 2
 MVCC에 대한 두 가지 접근법

2. Second Approach1. First Approach
10021
10021
10024
10008
10024
10011
10021
10021
10008
SELECT
(SCN 10023)
Data Blocks
Rollback Segment
레코드1
레코드2(v1)
레코드3
레코드4
「레코드 2(v1)」를
「레코드 2(v2)」로 갱신
파일 중에 4건의 레코드가
순서대로 나열됨
• 레코드 갱신처리 (UPDATE）
레코드1
레코드2(v1)
레코드3
레코드4
레코드2(v2)
레코드2(v1)에 삭제 표시가 생겨,
레코드2(v2)가 새롭게 추가되고
파일 사이즈도 증가됨

PG_DAY 201603. PostgreSQL MVCC – 2) MVCC에 대한 두 가지 접근법
Database PostgreSQL Oracle SQL Server
Storage for
Old Versions
In the main segment
(Heap/Index)
In the separate segment
(Rollback Segment/Undo)
In the separate database
(tempdb – known as version store)
Size of Tuple
Header (bytes)
24 3
Fixed – 4
Variable – 14
Clean up Vacuum System Monitor Process (SMON) Ghost Cleanup task
 PostgreSQL VS Oracle VS SQL Server

출처 http://www.siue.edu/~dbock/cmis565/module10-undo_data.htm 출처 https://riddle.ru/mirrors/oracledocs/server/scn73/ch1001.html
Table
Undo Image
New Image from the
Update DML Command
UPDATE employee
SET emp_addr =
…
SELECT emp_addr
FROM employee
WHERE …
10021
10021
10024
10008
10024
10011
10021
10021
10008
SELECT
(SCN 10023)
Data Blocks
Rollback Segment
Read Consistency
CR Block 생성
03. PostgreSQL MVCC – 2) MVCC에 대한 두 가지 접근법
 Oracle

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Typ Fmt Filler RDBA SCNBase SCN Wrap Seq Flg
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ChkVal Filler Ktbbhtyp Ktbbhdsid,Obj id csc
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
ktbbhcsc itc flg fsl Bdba(next dba) First Itl
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
(xid + uba + scn/fsc)
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
Second itl (xid + uba + scn/fsc)
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
xid filler
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
filelr Flg ntab nrow Frre=-1 fsbo fseo avsp
112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
tosp offs nrows Offs 1 Offs 2
8144 8145 8146 8147 8148 8149 8150 8151 8152 8153 8154 8155 8156 8157 8158 8159
8160 8161 8162 8163 8164 8165 8166 8167 8168 8169 8170 8171 8172 8173 8174 8175
8176 8177 8178 8179 8180 8181 8182 8183 8184 8185 8186 8187 8188 8189 8190 8191
tailchk

Special
Page
Header
Tuple1Tuple2Tuple3
Tuple Header
line pointer2000
801f
Free Space

t_xmin t_xmax
t_field3
(cmin,cmax,t_xvac)
• t_xmin: insert 시의 XID
• t_xmax: delete 시의 XID
• t_field3: t_cid, t_xvac 로 구성
• t_cid: insert, delete command id (cmin, cmax)
• t_xvac: 이전 full vacuum의 트랜잭션 ID를 추적 가능
• t_ctid: 해당 튜플의 현재 버전을 가리키는 포인터
block id data(4bytes) + offset number (2bytes)
• t_infomask2: 앞의 2자리는 변경 커맨드 정보, 뒤의 2자리는 컬럼 수
• t_infomask: commit 여부
• t_hoff: 튜플 헤더의 길이, 유저 데이터의 시작 주소
• t_bits: null 값의 variable length bitmap

출처: http://pgsqldeepdive.blogspot.kr/2012/12/postgresql_16.html
오라클처럼 replace되는 것이 아니라
레코드2(v1)에 삭제 표시(xmax)가 생겨,
레코드2(v2)가 새롭게 추가되고 파일 사이즈도 증가됨
파일 중에 4건의 레코드가 순서대로 나열됨
「레코드 2(v1)」를
「레코드 2(v2)」로 갱신
xmin 레코드1
xmax,
infomask2,
infomask
레코드2(v1)
xmin 레코드3
xmin 레코드4
xmin,
infomask2,
infomask
레코드2(v2)
xmin 레코드1
xmin 레코드2 (v1)
xmin 레코드3
xmin 레코드4
 PostgreSQL - 레코드 갱신처리（UPDATE）

 PostgreSQL - 레코드 갱신처리（UPDATE）
② update t2 set c2='B' where c1 = 'A1001' ;예)
pd_lower
(freespace 시작)
pd_upper
(freespace 끝)
items
t_xmin
t_xmax
t_infomask2
t_infomask

PostgreSQL Deep Internal03. PostgreSQL MVCC
• SCN은 커밋 시마다 순차적으로 증가하며, 6bytes 사용됨
• 초당 1만 번의 커밋이 발생한다고 하더라도 대략, 800년 이상
(26*8 / (10,000 * 86,400 * 365)이 지나야 오버플로우 발생
김시연, 최영준 『Transaction Internals in Oracle 10g R2』, 엑셈(2008)
• 트랜잭션 ID는 32bit 정수형 크기
• 하나의 클러스터 기준으로 관리되기 때문에, 서버가 40억(232)
트랜잭션을 넘게 사용했다면 트랙잭션 ID 겹침 오류를 발생
출처 http://postgresql.kr/docs/9.3/routine-vacuuming.html

…
Array
UPDATE 100
100
A …
100
A B
A B C
A B C D
…

Special
Page
Header
Tuple1, A
line pointer
03. PostgreSQL MVCC
• Insert (Tuple1, A)
001c
1d10
세션1 세션2 세션3
t_xmin 2a9
t_xmax 0
ctid (0,1)
Tuple 1, A
t_xmin 2a9
t_xmax 0
t_ctid (0,1)
세션0
Begin;
Insert (Tuple1, A)
Commit;
①
② Read Only 후, Select
ctid
(0,1)
Free Space

Special
Page
Header
Tuple1, A
03. PostgreSQL MVCC
• Update (Tuple1, B)
t_xmin 2a9
t_xmax 2aa
t_ctid (0,2)
Tuple1, B
line pointer0020
1a20
t_xmin 2aa
t_xmax 0
t_ctid (0,2)
Select② Read Only 후, Select③
t_xmin 2a9
t_xmax 2aa
ctid (0,1)
Tuple 1, A
t_xmin 2aa
t_xmax 0
ctid (0,2)
Tuple 1, B
ctid
(0,1)
ctid
(0,2)
세션0
Begin;
Update (Tuple1, B)
Commit;
①
Free Space

Special
Page
Header
Tuple1, A
t_xmin 2a9
t_xmax 2aa
t_ctid (0,2)
Tuple1, B
0024
1730
t_xmin 2aa
t_xmax 2ab
t_ctid (0,3)
Select② Select③
ctid
(0,1)
t_xmin 2a9
t_xmax 2aa
ctid (0,1)
Tuple 1, A
t_xmin 2aa
t_xmax 2ab
ctid (0,2)
Tuple 1, B
Tuple1, C
line pointer
ctid
(0,2)
ctid
(0,3)
Read Only 후, Select④
t_xmin 2ab
t_xmax 0
ctid (0,3)
Tuple 1, C
• Update (Tuple1, C)
t_xmin 2ab
t_xmax 0
t_ctid (0,3)
세션0
Begin;
Update (Tuple1, C)
Commit;
①
03. PostgreSQL MVCC
Free Space

Special
Page
Header
Tuple1, A
03. PostgreSQL MVCC
Tuple1, B
0028
1440
t_xmin 2aa
t_xmax 2ab
t_ctid (0,3)
Select② Select③
ctid
(0,1)
t_xmin 2a9
t_xmax 2aa
ctid (0,1)
Tuple 1, A
t_xmin 2aa
t_xmax 2ab
ctid (0,2)
Tuple 1, B
Tuple1, C
ctid
(0,2)
ctid
(0,3)
Select④
t_xmin 2ab
t_xmax 2ac
ctid (0,3)
Tuple 1, C
• Update (Tuple1, D) ctid
(0,4)
Tuple
1, D
line pointer
t_xmin 2ab
t_xmax 2ac
t_ctid (0,4)
t_xmin 2a9
t_xmax 2aa
t_ctid (0,2)
t_xmin 2ac
t_xmax 0
t_ctid (0,4)
세션0
Begin;
Update (Tuple1, D)
Commit;
①
Free Space

Special
Page
Header
Tuple1, A
03. PostgreSQL MVCC
• Update (Tuple1, B)
세션1 세션2
t_xmin 2a9
t_xmax 2aa
t_ctid (0,2)
Tuple1, B
line pointer0020
1a20
t_xmin 2aa
t_xmax 0
t_ctid (0,2)
t_xmin 2a9
t_xmax 2aa
ctid (0,1)
Tuple 1, A
Lock
ctid
(0,1)
ctid
(0,2)
세션0
Begin;
Update (Tuple1, B)
Commit은 안함
①
Select② Update (Tuple1, C)③
Free Space

 Oracle
• 시간 정보 “SCN”과 공간 정보 “XID”를 복합적으로 활용하여 트랜잭션을 처리함
• 이전 이미지가 저장되어 있는 언두 레코드의 주소를 가리키는 “uba”
• Commit SCN은 트랜잭션이 완료될 때 부여됨
 PostgreSQL
• 다음 이미지를 가리키는 “t_ctid”
• XID가 트랜잭션이 시작할 때 붙여지기 때문에 “Snapshot”이 필요
 MySQL
• 이전 이미지를 가리키는“roll pointer”
• XID가 트랜잭션이 시작할 때 붙여지기 때문에 “Readview”가 필요
• Snapshot structure
출처 - https://www.postgresql.org/files/developer/internalpics.pdf

100
t_xmin t_xmax
SELECT (XID 90)
104101
110104
105
100
t_xmin t_xmax
SELECT (XID 106)
104101
110104
105
100
t_xmin t_xmax
SELECT (XID 120)
104101
110104
105
• 시나리오
Transaction Counter at query start: 90, 106, 120
Open Transaction: 105
105는 open transaction이기
때문에 읽지 못함

04. Page Layout

PostgreSQL Deep Internal04. Page Layout - 1) Overall Page Layout
Special
Page Header
Tuple1Tuple2Tuple3
Tuple Header
2000
801f
line pointer
Free Space

• Page Header Data: 페이지에 대한 전반적 정보
• Item Id Data(line pointer): 실제 아이템을 가리키는 포인터로 offset, length에 대한 정보, 아이템 당 4bytes
• Free space: 할당되지 않은 공간
• Items: 실제 아이템에 대한 정보
• Special space: 일반 테이블에서는 빈 공간
 Dump
04. Page Layout - 1) Overall Page Layout

PostgreSQL Deep Internal04. Page Layout - 2) Page Header Data Layout
Special
Page Header
Tuple1Tuple2Tuple3
line pointer
Tuple Header
2000
801f
Free Space

• pd_lsn: 이 페이지의 가장 마지막 변경에 대한 xlog record
• pd_checksum: 페이지 체크섬
• pd_flags: 플래그 비트
• pd_lower: freespace의 시작
• pd_upper: free space의 끝이자 items의 시작
• pd_special: special space의 시작
• pd_pagesize_version: 페이지 크기 (2004: 8196 = 8k)
• pd_prune_xid: xmax중 가장 오래된 값(작은 값)
 Dump
04. Page Layout - 2) Page Header Data Layout

Special
Page Header
Tuple1Tuple2Tuple3
line pointer
Tuple Header
04. Page Layout - 3) Item Id Data
2000
801f
Free Space

• 실제 아이템을 가리키는 Item Id Data는 lp_off(15bit), lp_flags(2bit), lp_len(15bit) 총 4byte로 구성되어 있다.
• 예를 들어, Item Id Data인 ‘c0 9f 7c 00’ 은 순서를 거꾸로 하여 ‘00 7c 9f c0’ 에서 뒤의 4자리에서 맨
앞의 1bit 를 제외한 ‘1fc0’을 통해 Item을 찾아갈 수 있다.
 Dump 00 7c 9f c0
• lp(line pointer): 블록 내의 아이템 offset ID
• lp_off: 튜플의 offset (주소)
• lp_flags: 아이템 포인터의 상태
• lp_len: 튜플의 길이
lp_unused: 0
lp_normal: 1
lp_redirect: 2
lp_dead: 3
‘00 7c 9f c0’= 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 1 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0
lp_len
(15 bit)
lp_flags
(2 bit)
lp_off
(15 bit)
04. Page Layout - 3) Item Id Data
0 0 7 c 9 f c 0

Special
Page Header
Tuple1Tuple2Tuple3
Tuple Header
line pointer2000
801f
04. Page Layout - 4) Heap Tuple Header Data Layout
Free Space

PostgreSQL Deep Internal04. Page Layout - 4) Heap Tuple Header Data Layout
t_xmin t_xmax
t_field3
(cmin,cmax,t_xvac)
• t_xmin: insert 시의 XID
• t_xmax: delete 시의 XID
• t_field3: t_cid, t_xvac 로 구성
• t_cid: insert, delete command id (cmin, cmax)
• t_xvac: 이전 full vacuum의 트랜잭션 ID를 추적 가능
• t_ctid: 해당 튜플의 현재 버전을 가리키는 포인터
block id data(4bytes) + offset number (2bytes)
• t_infomask2: 앞의 2자리는 변경 커맨드 정보, 뒤의 2자리는 컬럼 수
• t_infomask: commit 여부
• t_hoff: 튜플 헤더의 길이, 유저 데이터의 시작 주소
• t_bits: null 값의 variable length bitmap

t_xmin t_xmax
t_field3
t_cid/t_xvac
t_ctid 중
block id data
4bytes 4bytes 4bytes 4bytes
t_ctid 중
offset
t_infomas
k2
t_infomask t_hoff 사용자
2 bytes 2 bytes 2 bytes 1 bytes 9bytes
001380 69 31 00 00 6b 31 00 00 00 00 00 00 00 00 00 00 >i1..k1..........<
001390 64 00 01 20 02 01 18 00 11 31 39 39 20 20 20 20 >d.. .....199 <
예)

PostgreSQL Deep Internal04. Page Layout - 4) Heap Tuple Header Data Layout
 Dump 00 7c 9f 80
 SELECT * from heap_page_items(get_raw_page('t2', 0));
• heap_page_items : 테이블 내의 데이터
• get_raw_page : 페이지를 나타내는 byte array

Name Body Description
HEAP_NATTS_MASK
0x07FF 11 bits for number of attributes
0x1800 bits 0x1800 are available
HEAP_KEYS_UPDATED 0x2000 tuple was updated and key cols modified, or tuple deleted
HEAP_HOT_UPDATED 0x4000 tuple was HOT-updated
HEAP_ONLY_TUPLE 0x8000 this is heap-only tuple
HEAP2_XACT_MASK 0xE000 visibility-related bits
 t_infomask2

 t_infomask2
Command Dump Meaning
commit
insert 0003
delete 2003
rollback 0003
0003
0x0003
number of attributes (컬럼 수 3개)
0x000
2003
0x0003
0x2000
tuple was updated and key cols
modified or tuple deleted
0003
0x0003
0x000

HEAP_HASNULL 0x0001 has null attribute(s)
HEAP_HASVARWIDTH 0x0002 has variable-width attribute(s)
HEAP_HASEXTERNAL 0x0004 has external stored attribute(s)
HEAP_HASOID 0x0008 has an object-id field
HEAP_XMAX_KEYSHR_LOCK 0x0010 xmax is a key-shared locker
HEAP_COMBOCID 0x0020 t_cid is a combo cid
HEAP_XMAX_EXCL_LOCK 0x0040 xmax is exclusive locker
HEAP_XMAX_LOCK_ONLY 0x0080 xmax, if valid, is only a locker
 t_infomask

HEAP_XMIN_COMMITTED 0x0100 t_xmin committed
HEAP_XMIN_INVALID 0x0200 t_xmin invalid/aborted
HEAP_XMIN_FROZEN 0X0300 (HEAP_XMIN_COMMITTED | HEAP_XMIN_INVALID)
HEAP_XMAX_COMMITTED 0x0400 t_xmax committed
HEAP_XMAX_INVALID 0x0800 t_xmax invalid/aborted
HEAP_XMAX_IS_MULTI 0x1000 t_xmax is a MultiXactId
HEAP_UPDATED 0x2000 this is UPDATEd version of row
HEAP_MOVED_OFF 0x4000
• moved to another place by pre-9.0
• VACUUM FULL; kept for binary
• upgrade support
HEAP_MOVED_IN 0x8000
• moved from another place by pre-9.0
• VACUUM FULL; kept for binary
• upgrade support
HEAP_XACT_MASK 0xFFF0 visibility-related bits
 t_infomask

 t_infomask
commit
insert 0902
delete 0502
update
delete : 0502
insert : 2902
0902
0x0002
variable-width attributes
0x0900
( 0x0100 + 0x0800 )
xmin committed + xmax invalid
0502
0x0002
0x0500
( 0x0100 + 0x0400 )
xmin committed + xmax committed
2902
0x0002
0x2900
( 0x2000 + 0x0900 )
updated version of row + insert와 동일

 t_infomask
rollback 0A02
cf) null이 있는 경우
insert : 0903
rollback : 0A03
0A02
0x0002
0x0A00
( 0x0200 + 0x0800 )
xmin invalid + xmax invalid
0A03
0x0003
( 0x0001 + 0x0002 )
has null attribute(s) + variable-width
0x0A00
( 0x0200 + 0x0800 )
xmin invalid + xmax invalid
attributes

insert 1건 (1,A, ), commit NO
Page Header pd_lower, pd_upper
Line Pointer
infomask2 infomaskt_xmin t_xmax

insert 1건 (1,A, ), commit NO commit YES
• pd_lower 001c
• pd_upper 1fc0
• line pointer 007e9fc0
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask2 0003
• t_infomask 0802
• pd_lower 001c
• pd_upper 1fc0
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 09028 : xmax invalid/ aborted
8 : xmax invalid/ aborted
1: xmin committed

0000
xmax
invalid/aborted
xmax
committed
xmin
invalid/aborted
xmin
committed
21 202223
1 0 0 1
0 10 0
1 00 0
0 11 0
insert commit NO
insert commit YES
delete commit NO
delete commit YES
cf) update 2xxx
frozen bit XbXX
 t_infomask

insert 1건 (2,A, ) commit YES
• pd_lower 0020
• pd_upper 1f80
007e9f80
(2,A, )
• t_xmin 000001d5
• t_xmax 00000000
• t_infomask 0902
(1,A, )
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 0902

insert 1건 (3,A, ) commit YES
• pd_lower 0024
• pd_upper 1f40
007e9f80
007e9f40
(3,A, )
• t_xmin 000001d6
• t_xmax 00000000
• t_infomask 0902
(2,A, )
• t_xmin 000001d5
• t_xmax 00000000
• t_infomask 0902
(1,A, )
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 0902

• pd_lower 0024
• pd_upper 1f40
007e9f80
007e9f40
(3,A, )
• t_xmin 000001d6
• t_xmax 000001d7
• t_infomask 0102
(2,A, )
• t_xmin 000001d5
• t_xmax 00000000
• t_infomask 0902
(1,A, )
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 0902
delete 1건 (3,A, ) commit NO

• pd_lower 0024
• pd_upper 1f40
007e9f80
007e9f40
(3,A, )
• t_xmin 000001d6
• t_xmax 000001d7
• t_infomask 0502
(2,A, )
• t_xmin 000001d5
• t_xmax 00000000
• t_infomask 0902
(1,A, )
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 0902
delete 1건 (3,A, ) commit YES

insert 1건(3,A, ) commit YES
(3,A, )
• t_xmin 000001d8
• t_xmax 00000000
• t_infomask 0902
(3,A, )
• t_xmin 000001d6
• t_xmax 000001d7
• t_infomask 0502
(2,A, )
• t_xmin 000001d5
• t_xmax 00000000
• t_infomask 0902
(1,A, )
• t_xmin 000001d4
• t_xmax 00000000
• t_infomask 0902
• pd_lower 0028
• pd_upper 1f00
007e9f80
007e9f40
007e9f00

update 1건(3,B, ) commit NO
• pd_lower 002c
• pd_upper 1ec0
007e9f80
007e9f40
007e9f00
007e9ec0
• t_xmin 000001d9
(3,B, ) • t_xmax 00000000
• t_infomask 2802
• t_xmin 000001d8
(3, A, ) • t_xmax 000001d9
update • t_infomask2 4003
• t_infomask 0102
• t_xmin 000001d6
(3,A, ) • t_xmax 000001d7
delete • t_infomask2 2003
• t_infomask 0502

update 1건(3,B, ) commit YES
• pd_lower 002c
• pd_upper 1ec0
007e9f80
007e9f40
007e9f00
007e9ec0
• t_xmin 000001d9
(3,B, ) • t_xmax 00000000
• t_infomask 2902
• t_xmin 000001d8
(3,A, ) • t_xmax 000001d9
update • t_infomask2 4003
• t_infomask 0502
• t_xmin 000001d6
(3,A, ) • t_xmax 000001d7
delete • t_infomask2 2003
• t_infomask 0502

만약 1억 건을 update 한 후에 Commit을 한다면,
1억 건에 대해서 모두 완료하기까지 시간이 얼마나 소요될까?
Question

05. Vacuum
1) Vacuum 정의 및 필요성
2) Vacuum 실행 구조
3) 표준 Vacuum VS Vacuum full
4) XID Wraparound 와 Freeze
5) VM과 FSM 구조 분석
6) Autovacuum

PostgreSQL Deep Internal05. Vacuum - 1) Vacuum 정의 및 필요성
‘Multi Generation Architecture’의 단점은?
데이터의 변경이 빈번할 경우, 파일 사이즈가 커져 심각한 성능저하의 원인이 될 수 있다!
그렇다면 이를 해결해주는 기능은?
VACUUM!

PostgreSQL Deep Internal05. Vacuum - 1) Vacuum 정의 및 필요성
1) 변경 및 삭제된 자료들이 차지하고 있는 디스크 공간을 확보하기 위해서
2) transaction id가 겹침(wraparound)으로 인해 오래된 자료의 손실이 발생하는 것을 방지하기 위해서
3) Query Planner가 사용할 자료의 통계 정보를 갱신하기 위해서
4) 실자료 지도(visibility map, VM)의 정보를 갱신하기 위해서
(VM은 인덱스 전용의 검색 성능을 향상시키기 위해 사용함)
2. Vacuum의 필요성
1. Vacuum의 정의
PostgreSQL에서 특정 튜플을 update 하거나 delete 한다고 해서 해당 영역이 자동으로 재사용되거나 사라지지 않는다.
이렇게 오래된 영역을 정리하여 공간을 반환하는 명령어가 Vacuum이다. ≒ 디스크 조각 모음
VM (Visibility Map)
dead tuple의 존재 여부를 알려주는 정보
• dead tuple이 포함되지 않은 경우 : 1
• dead tuple이 포함되거나 확실하지 않은 경우 : 0

PostgreSQL Deep Internal05. Vacuum - 2) Vacuum 실행 구조
① insert into t2 values('A1001','A','A');
insert into t2 values('A1002','A','A');
② update t2 set c2='B' where c1 = 'A1001' ;
③ 표준 vacuum ④ Full vacuum
'A1001',‘B','A'

PostgreSQL Deep Internal05. Vacuum - 3) 표준 vacuum VS Vacuum full
③ 표준 vacuum ④ Full vacuum
pd_lower
pd_upper
itemst_xmin
t_infomask2
t_xmax
t_infomask
pd_prune_xid

Special
Page Header
'A1001','A','A''A1002','A','A'
line pointer
Tuple Header
05. Vacuum - 3) 표준 vacuum VS Vacuum full
• insert into t2 values('A1001','A','A');
• insert into t2 values('A1002','A','A');
2000
801f
Free Space

• SELECT * from heap_page_items(get_raw_page('t2', 0));
05. Vacuum - 3) 표준 vacuum VS Vacuum full
create table t2 ( c1 char(19),c2 char(8),c3 char(8) );
• extension module
create extension pageinspect;

• update t2 set c2='B' where c1 = 'A1001' ;
Special
Page Header
'A1001','A','A''A1002','A','A''A1001', 'B','A'
line pointer
Tuple Header
2400
401f
새로운 위치/에 변경 데이터인
“B” 레코드를 추가
“A1001” 원본은
“xmax” 값을 변경
Free Space

• select xmin,xmax,ctid, * from t2;
“A1001” item 의 xmin 변경됨
“A1001” 원본은

“A1001” item 의 xmin 변경됨
“A1001” 원본은
새로운 위치에 변경 데이터인
“B” 레코드를 추가

Special
Page Header line pointer
Tuple Header
'A1002','A','A''A1001', 'B','A'
• 표준 Vacuum
A의 line pointer는 삭제되나 공간은 남아있고, items에는 공간도 삭제된다. free space가 증가된다.
그러나 items에서 실제로 데이터있는 것처럼 보인다.
2400
801f
A1001 위치도 아래로 변경 A1002가 제일 아래로 내려감
A1001 원래 위치의 데이터는
그대로 두고 Item Id Data만 삭제
'A1001',‘B','A'
Free Space

③ 표준 vacuum
A1001 원래 위치의 데이터는 그대로 두고 Item Id Data만 삭제

③ 표준 vacuum
A1002가 제일 아래로 내려감

③ 표준 vacuum
A1002가 제일 아래로 내려감
A1001 위치도 아래로 변경

• Full Vacuum
Full Vacuum을 하면 삭제되지 않았던 line pointer의 공간도 삭제된다.
Special
Page Header
'A1002','A','A''A1001',‘B','A'
Tuple Header
2000
801f
line pointer
line pointer 삭제
Free Space

④ Full vacuum
line pointer 삭제

표준 vacuum Vacuum full
처리 방식
• 다른 자료가 저장될 수 있도록 빈 공간으로 표시
• OS 입장에서는 디스크의 여유 공간 확보가 불가
• 새 파일에 저장하는 방식
(pg_class의 relfilenode값이 변경)
• OS 입장에서 디스크의 여유 공간 확보가 가능
• 최적의 물리적 크기로 테이블 생성
처리 속도 Vacuum full 보다는 시간이 적게 걸림 처리 속도가 매우 느려 시간이 오래 걸림
Lock 여부
여러 다른 작업들과 함께 사용 가능
select, update, insert, delete (단, ALTER TABLE는 안됨)
해당 테이블에 배타적 잠금을 지정하기 때문에 어떤 작업도
함께 사용할 수 없음

12735 12755 12775 12793_fsm 12809 12825_fsm 12845 12862_vm 12910 12925 12949 12968_vm 12988_fsm
12735_fsm 12756 12776 12793_vm 12809_fsm 12825_vm 12846 12864 12910_fsm 12925_fsm 12953 12970 12988_vm
12735_vm 12757 12776_fsm 12795 12809_vm 12827 12847 12865 12910_vm 12925_vm 12953_fsm 12972 12990
12737 12757_fsm 12776_vm 12796 12811 12828 12847_fsm 12866 12912 12927 12953_vm 12973 12992
12737_fsm 12757_vm 12778 12797 12812 12828_fsm 12847_vm 12866_fsm 12913 12928 12955 12973_fsm 12993
12737_vm 12759 12780 12797_fsm 12813 12828_vm 12849 12866_vm 12913_fsm 12929 12956 12973_vm 12995
12739 12761 12781 12797_vm 12814 12830 12851 12868 12913_vm 12931 12957 12975 12997
12740 12762 12782 12799 12814_fsm 12830_fsm 12852 12869 12915 12932 12957_fsm 12977 pg_filenode.map
12741 12763 12783 12800 12814_vm 12830_vm 12853 12870 12916 12933 12957_vm 12978 PG_VERSION
12741_fsm 12764 12784 12801 12816 12832 12853_fsm 12871 12917 12935 12959 12978_fsm
12741_vm 12764_fsm 12785 12801_fsm 12817 12833 12853_vm 12871_fsm 12917_fsm 12936 12960 12978_vm
12743 12764_vm 12787 12801_vm 12818 12834 12855 12871_vm 12917_vm 12937 12962 12980
12744 12766 12788 12803 12818_fsm 12835 12856 12873 12919 12939 12963 12982
12749 12767 12789 12804 12818_vm 12837 12857 12874 12920 12940 12963_fsm 12983
12751 12768 12789_fsm 12805 12820 12839 12859 12906 12921 12942 12963_vm 12983_fsm
12752 12769 12789_vm 12805_fsm 12821 12840 12860 12906_fsm 12921_fsm 12943 12965 12983_vm
12753 12771 12791 12805_vm 12822 12841 12861 12906_vm 12921_vm 12944 12967 12985
12753_fsm 12773 12792 12807 12824 12842 12862 12908 12923 12946 12968 12987
12753_vm 12774 12793 12808 12825 12843 12862_fsm 12909 12924 12948 12968_fsm 12988
 DB 생성 후, 무엇이 생성되는가?
 DB 생성 시 생성되는 파일들
select * from pg_class where relfilenode='12735’;

표준 Vacuum
 표준 Vacuum, Full Vacuum 후, 각각의 결과
Full Vacuum
Vacuum 전

PostgreSQL Deep Internal05. Vacuum - 4) XID Wraparound 와 Freeze
• 트랜잭션에 대한 MVCC 기법:
XID(트랜잭션 ID)를 숫자로 처리하고 비교
• 232 까지 표현이 가능 (대략 40억)
• 옛 XID(20억) + 새 XID(20억)
• 옛 XID 20억은 보이고, 새 XID 20억은 안보이게 처리
• 계속 순환하면서 사용
출처: http://www.slideshare.net/pgdayasia/introduction-to-vacuum-freezing-and-xid
Older (Visible)
옛 XID 20억
Newer (Invisible)
새 XID 20억
232

• XID wraparound 때문에 오래된 데이터에 대한 손실 발생
• Insert–only 테이블에서만 발생
출처: http://www.slideshare.net/hadoopxnttdata/postgresql-xid-wraparound-another-issue
Visible InvisibleVisible
Older
(Visible)
Older
(Visible) Older
(Visible)
Newer
(Invisible)
Newer
(Invisible)
Newer
(Invisible)
XID=100 XID=100XID=100
05. Vacuum - 4) XID Wraparound 와 Freeze

VisibleVisible
Older
(Visible)
Older
(Visible) Older
(Visible)
Newer
(Invisible)
Newer
(Invisible)
Newer
(Invisible)
XID=100
FREEZEXID=100
• 튜플을 “FREEZE”로 표시하고, 이 FrozenXID는 일반 XID 비교 대상에서 항상 제외되어 항상 보여짐
• 20억 트랜잭션이 생기기 전에 FrozenXID 즉, 영구 보관용 자료로 변경하면 XID 겹침 오류 방지
• 이러한 변경 작업(data freezing)은 VACUUM FREEZE 명령으로 처리
출처: http://www.slideshare.net/hadoopxnttdata/postgresql-xid-wraparound-another-issue
Visible
XID=100
FREEZE

XID
WraparoundCurrent XID
pg_class.
relfrozenxid
Anti-wraparound
Vacuum
vacuum_freeze_table_age (1.5억)
autovacuum_freeze_max_age (2억)
+20억
vacuum_freeze_min_age (0.5억)
Vacuum Count = 0
Forcibly
anti-wraparound
Vacuum
0.5 억이 넘어야만 vacuum freeze

XID
WraparoundCurrent XID
pg_class.
relfrozenxid
Whole table scan
?
Anti-wraparound
Vacuum
vacuum_freeze_table_age (1.5억)
autovacuum_freeze_max_age (2억)
+20억
vacuum_freeze_min_age (0.5억)
Vacuum Count > 0
Forcibly
anti-wraparound
Vacuum
1.5 억이 넘어야만 vacuum freeze

• psql -x < ./fsm_vm/tab.sql
• create table t2 ( c1 char(15),c2 char(15),c3 char(689) );
• INSERT INTO T2 SELECT 'Tuple'||generate_series(1001,2000),'A',' ';
 Vacuum Count = 0 시나리오
• Jump Current Xid  52,428,800 (pg_resetxlog)

• update t2 set c2='B' where c1 >= 'Tuple1700' ;
 Vacuum Count = 0 시나리오
• ./fsm_vm/pageinspect.sql

• create table t2 ( c1 char(15),c2 char(15),c3 char(689) );
• INSERT INTO T2 SELECT 'Tuple'||generate_series(1001,2000),'A',' ';
 Vacuum Count > 0 시나리오
• psql -c "vacuum freeze t2;"

• psql -c "update t2 set c2='B' where c1 > 'Tuple1700' ;"

• psql -c "update t2 set c2='C' where c1 > 'Tuple1700' ;"

PostgreSQL Deep Internal05. Vacuum - 5) Autovacuum
• Autovacuum launcher
Autovacuum_naptime 값으로 지정한 초 간격으로 한 번에 하나의
데이터베이스를 작업할 수 있도록 worker 프로세스의 실행 시간을 관리
• Autovacuum workers
Autovacuum_max_workers worker 프로세스 최대 개수
AUTOVACUUM이란? VACUUM 명령과 ANALYZE 명령을 주기적으로 자동 실행
• 주기적인 표준 Vacuum 작업을 하여 빈 공간을 확보하여 최대한 Vacuum Full 작업을 방지
• 최소의 디스크를 쓰는 것이 아닌 최적의 디스크 공간만 사용
출처: http://www.slideshare.net/alexeylesovsky/deep-dive-into-postgresql-statistics-60849690

Vacuum 작업은
내가 직접 작업량
이 적은 밤 시간에
주기적으로 해야지!
갑자기 변경이 많은 작업 발생 최악의 경우, Vacuum Full
DBA
• Autovacuum 데몬은 예상치 못한 상황에 대해 자동으로 Vacuum 작업을 진행하여 위와 같은 문제를 피할 수 있다.
• 정확한 데이터베이스 사용량을 파악하지 않고 autovacuum을 끄면 안 된다.
• Autovacuum 데몬을 사용하지 않는다면, 해당 DB 서버에서 사용하고 있는 모든 DB에 대해서 Vacuum 작업을 해야 한다.
• Autovacuum 데몬은 테이블 자료 추가/변경/삭제 된 경우, 무조건 작업의 고려 대상으로 판단한다.
(단, 임시 테이블은 대상에서 제외)

autovacuum_analyze_scale_factor
한 테이블 내에서 autovacuum_analyze_threshold 값이 초과되어 analyze 작업을
시작하려고 할 때, 추가적으로 테이블 크기의 변화량 (기본값은 0.1 = 테이블 크기의
10%)
autovacuum_vacuum_threshold / autovacuum_analyze_threshold
한 테이블 내에서 업데이트/삭제된 튜플이 설정 값만큼 된다면 vacuum/anaylze 작업
하는 수행, 작업 시작할 최소 변경 수 (기본 값 50)
autovacuum_freeze_max_age
한 테이블 내에서 마지막 vacuum 작업으로 pg_class.relfrozenxid 값이 지정된 뒤로,
이 설정 값보다 더 커지면 vacuum 작업 수행
autovacuum_naptime
autovacuum 데몬에 대한 “activity rounds 간격”즉, autovacuum 데몬이 한번 작업
하고 쉬는 시간 (기본 값 1분 – 초(秒)로 설정)
autovacuum_vacuum_cost_delay
autovacuum 데몬의 초과 비용 사용시, 멈추는 최대 시간 (기본 값 20 millisecond)
autovacuum_vacuum_cost_limit
autovacuum 데몬이 사용할 수 있는 최대 비용 (기본 값 -1)
autovacuum_vacuum_scale_factor
한 테이블 내에서 autovacuum_vacuum_threshold 값이 초과되어 vacuum 작업을 시
작하려고 할 때, 추가적으로 테이블 크기의 변화량 (기본값은 0.2 = 테이블 크기의 20%)

 Autovacuum의 작업 기준
05. Vacuum - 5) Autovacuum
1. 테이블 나이가 autovacuum_freeze_max_age 설정으로 지정한 트랜잭션 수보다 많다면, 그 테이블은 무조건 Vacuum 작업
• 테이블의 나이: relfrozenxid 칼럼 값을 age () 함수로 조사한 값
2. 테이블의 자료가 변경되어, Vacuum 임계치를 초과했다면, Vacuum 작업
* Vacuum 임계치 = Vacuum 초기 임계치 + Vacuum 배율값 * 튜플수
• Vacuum 초기 임계치: autovacuum_vacuum_threshold
• Vacuum 배율값: autovacuum_vacuum_scale_factor
• 튜플수: pg_class.reltuples
3. 테이블의 자료가 변경되어, Analyze 임계치를 초과했다면, Analyze 작업
* Analyze 임계치 = Analyze 초기 임계치 + Analyze 배율값 * 튜플수
• Analyze 초기 임계치: autovacuum_analyze_threshold
• Analyze 배율값: autovacuum_analyze_scale_factor
• 튜플수: pg_class.reltuples

autovacuum_vacuum_scale_factor = 0.2
autovacuum_vacuum_threshold = 50
1. 1000건 insert
2. autovacuum_naptime=60s 이상 wait 후 확인 : autovacuum NOT OK, autoanalyze OK.

4. autovacuum_vacuum_threshold=50 인 50건 update  wait 후 확인 : autovacuum NOT OK.
3. autovacuum_vacuum_scale_factor=0.2 인 200건 update  wait 후 확인 : autovacuum NOT OK.

5. Only 1건 update  wait 후 확인 : autovacuum OK.
 autovacuum vacuum 대상 조건 :
변경건수(insert 제외) > ( reltuples * 0.2(autovacuum_vacuum_scale_factor) ) + 50 (autovacuum_vacuum_scale_factor)

1. 1000건 insert
autovacuum_analyze_scale_factor = 0.1
autovacuum_analyze_threshold = 50
2. autovacuum_naptime=60s 이상 wait 후 확인 : autoanalyze OK.

3. autovacuum_analyze_scale_factor=0.1 인 100건 insert  wait 후 확인 : autoanalyze NOT OK.
4. autovacuum_analyze_threshold=50 인 50건 insert  wait 후 확인 : autoanalyze NOT OK.

5. Only 1건 insert  wait 후 확인 : autoanalyze OK.
 autovacuum analyze 대상 조건 :
변경건수(insert포함) > ( reltuples * 0.1(autovacuum_analyze_scale_factor) ) + 50 (autovacuum_analyze_scale_factor)

PostgreSQL Deep Internal05. Vacuum - 6) VM과 FSM 구조 분석
Visibility Map (≒ bitmap index)
• 각각의 heap relation은 VM을 통해 어떤 페이지가 모두 active 상태의 트랜잭션으로 보이는 튜플만 포함하는 지를 추적
• 메인 릴레이션 데이터를 따라서 저장이 되는데, filenode 번호 뒤에 ' _vm' 이라는 접미사가 붙는 형태로 생성
• 예를 들면, 릴레이션의 filenode가 ‘123’이면, vm은 ‘123_vm’ 형태로 생성
• 한 heap page당 1bit씩 저장
• bit는 vacuum 작업에 의해 설정이 되며, 페이지의 데이터 변경 작업에 의해서 clear될 수 있음

• 블록 1은 dead tuple 없는 ‘1’을 나타내므로 vacuum 작업이 필요 없다.
• 블록 2는 삭제된 튜플이 있기 때문에 ‘0’이 표시된다.
• 업데이트시에 새로 추가된 튜플은 dead tuple이 없지만 0으로 표시된다.
• Index-Only Scan시에 블록1의 튜플은 모두 존재한다고 알고있다.
출처: http://www.postgresqlinternals.org/index.php/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:4_9.jpg
레코드1
레코드3
레코드4
레코드2
레코드5
(레코드6)
레코드7
레코드8
레코드6’
레코드9
블록1
블록2
테이블A의 데이터 블록 테이블A의 Visibility Map (bitmap)
1 0
dead tuple이 없음
블록1 블록2
dead tuple 있을 수도 있고,
없을 수도 있음
05. Vacuum - 6) VM과 FSM 구조 분석

1. The visibility map simply stores one bit per heap page.
2. Visibility map bits are only set by vacuum, but are cleared by any data-modifying operations on a
page.
* Byte 단위로 한 bit씩 Little-endian 순서로 저장 ( 하위 비트부터 저장 )
 VM Layout
VM Header

1111 1110 1111 1111 1111 1111
0145 2367
A1080
...
A1084
A1085
...
A1089
A1100
...
A1104
A1105
...
A1109
A1110
...
A1114
A1040
...
A1044
A1045
...
A1049
A1050
...
A1054
A1060
...
A1064
A1065
...
A1069
A1070
...
A1074
A1075
...
A1079
A1000
...
A1004
A1005
...
A1009
A1020
...
A1024
A1025
...
A1029
1 2 3 4 5 6 70
16진수를 2진수로 변환

1. t2 테이블에 120건 insert ( 24페이지 생성, 1 페이지당 5건 )
2. vacuum 실행
3. vm 페이지 Dump  전부 visible 이므로 “1111 1111 1111 1111 1111 1111” ( ff ff ff - hexa )
insert into t2 SELECT 'A' || generate_series(1000,1000+120-1),'A','A';
vacuum t2 ;

1. 0번 페이지에서 1번째 레코드 삭제 * ctid ( 0,1 ) : 0번 페이지에서 1번째 레코드
2. vm 페이지 Dump  0번 페이지에 dead tuple이 발생해서 1번 Byte의 8번 Bit가 clear
“1111 1110 1111 1111 1111 1111”( fe ff ff – hexa )
delete from t2 where c1 = 'A1000' ;

1. 5번 페이지에서 1번째 레코드 삭제
“1101 1110 1111 1111 1111 1111”( de ff ff – hexa )

“1101 1110 1111 1011 1111 1111”( de fb ff – hexa )

2. vm 페이지 Dump  15번 페이지에 dead tuple 이 발생해서 2번 Byte의 1번 Bit가 clear
“1101 1110 0111 1011 1111 1111”( de 7b ff – hexa )

1. 16번 페이지에서 1번째 레코드, 17번 페이지에서 1번째 레코드를 삭제
2. vm 페이지 Dump  16,17번 페이지에 dead tuple이 발생해서 3번 Byte의 7,8번 Bit가 clear
“1101 1110 0111 1011 1111 1100”( de 7b fc – hexa )
delete from t2 where c1 in ( 'A1080','A1085' ) ;

1. 20번 페이지에서 1번째 레코드, 21번 페이지에서 1번째 레코드, 22번 페이지에서 1번째 레코드 삭제
2. vm 페이지 Dump  20,21,22번 페이지에 dead tuple이 발생해서 3번 Byte의 2,3,4번 Bit가 clear
“1101 1110 0111 1011 1000 1100”( de 7b 8c – hexa )
delete from t2 where c1 in ( 'A1100','A1105','A1110' ) ;

1. PostgreSQL 9.6 버전에서 frozen bit 추가
2. Anti-wraparound vacuum 작업할때 ‘1’로 setting 된 페이지는 Skip .
장점 : vacuum 작업성능 개선
단점 : vm 파일사이즈 2배 증가
9.6 Visibility Map

Vacuum Freeze 작업완료후 vm
확인결과
ff(Hexa Code)  11111111
9.6 Visibility Map
Vacuum 작업완료후 vm 확인결과
55(Hexa Code)  01010101

Free Space Map (≒ Freelist)
• 각 heap과 index relation은 fsm을 통해 릴레이션의 사용 가능한 공간을 추적
• 메인 릴레이션 데이터를 따라서 저장이 되는데, filenode 번호 뒤에 ' _fsm' 이라는 접미사가 붙는 형태로 생성
ex) 릴레이션의 filenode가 ‘123’이면, fsm은 ‘123_fsm’ 형태로 생성
• 각 fsm 페이지는 이진 트리로 구성되어 있으며 각 노드당 1byte
• 각 리프 노드는 heap page를 나타내거나 하위 레벨의 fsm 페이지를 나타냄
• 하위 레벨의 fsm 페이지에 각 heap 페이지의 사용 가능한 공간이 저장
• 상위 레벨은 하위 레벨로부터 모은 정보이기 때문에 루트는 최대값이 저장

• 28 (Header) + 8191(13 레벨의 총합) = 8219 bytes
• 8219 - 8192(8k) = 27 bytes 초과
• 마지막 레벨인 4096 bytes 중 27 bytes 모자람 = 4069 bytes 즉, 페이지당 관리할 수 있는 블록의 수 4069개
• 만약 FSM이 초과된다면 페이지가 하나 더 생김
Header (28 byte)
2
4
8
16
4069
…(8k = 8192 bytes)
13 레벨
…
Header (28 byte)
2
4
8
16
4069
…
…
1 1
(8k = 8192 bytes)

• 블록마다 1byte를 사용해서 공간을 BLCKSZ/ 256으로 나눈 값 유지 (1byte = 8bit = 28 =256)
• FSM value = Free space / (BLCKSZ/ 256) ex) 1024 / (8192/256) = 32
FSM Header
 FSM Layout
.
.
..
.
56
56 00
56 00
56 13
56
56
13
leafnode
1번 페이지
Free space
2번 페이지
Free space

• 1 페이지에 7건의 레코드가 적재된다.
• 21건의 레코드를 insert하면 3 페이지가 생성되고, FSM에는 2개만 보인다.
• CREATE TABLE
• INSERT 0 21
FSM 2개
.
.
..
.
13
13 00
13 00
13 13
13

• Vacuum 작업이 처리되면 FSM에 반영이 된다.
VACUUM
.
.
..
.
13
13 00
13 00
13 13
13
FSM 3개
13
13 00

• 2건을 delete 하면, FSM에 반영이 안 된다.
DELETE 2
.
.
..
.
13
13 00
13 00
13 13
13
FSM 3개
13
13 00

• Vacuum 작업이 처리되면 FSM에 반영이 된다.
VACUUM
.
.
..
.
56
56 00
56 00
56 13
56
56
13
13 00

• 19건을 Update 하면 페이지가 6개로 늘어나는데, FSM에는 반영이 되지 않는다. (5개)
UPDATE 19
.
.
..
.
13
13 00
13 00
13 13
13
13
13
13
13 00
13 13 13 00 FSM 5개

• Vacuum 작업이 처리되면 FSM에 반영이 된다. (6개 확인)
VACUUM
.
.
..
.
fe
fe 00
fe 00
bb fe
fe
fe
fe
9a
9a 00
fe 13 13 9a FSM 6개

cafe.naver.com/playexem
Q & A

NAVER http://cafe.naver.com/playexem
ITPUB (中) http://blog.itpub.net/31135309/
Wordpress https://playexem.wordpress.com/
Slideshare http://www.slideshare.net/playexem
교육 문의: 연구컨텐츠팀 김숙진
edu@ex-em.com
• EXEM Research & Contents Team
Youtube https://www.youtube.com/channel/UC5wKR_-
A0eL_Pn_EMzoauJg
Tudou (中) http://www.tudou.com/home/maxgauge/

Thank You
cafe.naver.com/playexem

PostgreSQL Deep Internal

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to PostgreSQL Deep Internal (20)

More from EXEM (15)

PostgreSQL Deep Internal