분류 전체보기 (88) 썸네일형 리스트형 Parallel Processing (병렬 처리) Parallel Processing ▪ PostgreSQL 9.6 부터 병렬 처리를 지원한다. ▪ 병렬 처리는 Parallel Scan, Parallel Group by, Parallel Join을 지원한다. ▪ ORACLE과 같은 생산자-소비자 모델은 아니다. Worker 프로세스 개수 산정 방식 ▪ Worker 프로세스의 개수는 min_parallel_relation_size 파라미터값을 기준으로 산정한다. ▪ 기준 크기의 3배 단위로 1개씩 증가하며, 최대 7개이다. Parallel Index Scan ▪ PostgreSQL 10부터는 Parallel Index Scan 기능을 제공한다. ▪ Parallel Index Scan 기능은 Index Full Scan 뿐만 아니라 Index Range S.. BRIN BRIN ▪ BRIN은 PostgreSQL 9.5부터 제공되는 인덱스 유형이다. ▪ BRIN은 블록 내의 MIN/MAX 값을 이용해서 블록 단위로 인덱싱한다. ▪ 이로 인해 인덱스 크기는 매우 작아진다는 장점이 있다. 이러한 장점으로 인해, 디스크 공간이 부족한 경우에는 BRIN을 선택하기도 한다. ▪ BRIN과 EXADATA의 Storage 인덱스는 매우 흡사하다 BRIN의 특성 ▪ BRIN의 크기는 매우 작다. 예를 들어, 1Gb 테이블인 경우에 BRIN의 크기는 6블록이다. (1MB 단위로 1개의 Min/Max 값을 저장하기 때문이다) ▪ 1건을 읽어도 128 블록 (1 MB)를 읽는다. ▪ BRIN은 Index Only Scan 방식보다는 느리다. 왜냐면 반드시 테이블을 액세스하기 때문이다. ▪ .. 힌트의 필요성과 PG_HINT_PLAN 힌트의 필요성과 PG_HINT_PLAN ▪ 특정 인덱스를 지정하거나, 조인 순서를 지정하거나, 여러 개의 테이블 간의 조인 방법을 각 조인마다 다르게 선택하는 것을 사용자가 지정할 수 있다면, 이는 매우 강력한 무기일 것이다. ▪ ORACLE은 Hint를 이용해서 이러한 작업을 수행할 수 있다. ▪ 다행히 PG_HINT_PLAN 이란 기능이 제공된다. ▪ 이는 Hint 가 아니라 Plan Tree 자체를 변경하는 기법이다. ▪ 따라서 Hint와 달리 Optimizer는 PG_HINT_PLAN을 무시할 수 없다. ▪ 즉, 매우 강력하면서도 위험한 무기인 셈이다. PG_HINT_PLAN 설치 PG_HINT_PLAN이 제공하는 Hint들 Query Rewrite (쿼리 변환) ▪ 사용자가 작성한 쿼리를 Optimizer가 더 좋은 실행계획을 수립할 수 있는 형태로 변경하는 것을 Query Rewrite라고 한다. 1) 서브 쿼리 Collapse : 서브 쿼리를 Main 쿼리에 병합하는 기법 (Sub query unnest) 2) View Merging : 뷰 또는 인라인 뷰를 풀어헤쳐 테이블 간의 조인으로 변경하는 방법 3) JPPD(조인 조건 push down) : View Merging이 실패한 경우, 조인 조건을 뷰 내부로 밀어 넣는 방법 View Merging ▪ 뷰를 풀어헤쳐서 테이블 간의 조인으로 변경함으로써 , 다양한 조인 순서와 조인 방법을 선택할 수 있다. 이때 View는 2개로 구분된다. ▪ Simple View는 항상 View Merging에 성공한다. ▪.. JOIN PostgreSQL에서 지원하는 조인 방법 ▪ Nested Loop 조인 ▪ Sort Merge 조인 ▪ 해시 조인 (Hybrid 해시 조인 지원) Nested Loop Join NL 조인 시에 Materialize가 발생하면 인덱스 생성을 고려해야 한다. ▪ NL 조인 시에 연결 고리에 인덱스가 없으면 Materialize 오퍼레이션이 발생할 수 있다. ▪ 이는 보완책이지 해결책이 아니다. 따라서 인덱스 생성을 고려해야 한다 Hash Join ▪ 해시 조인은 해시 함수를 이용한다. 해시 함수(h)는 다음과 같은 특성을 갖는다. 1. X=Y이면 반드시 h(X)=h(Y) 이다. 2. h(X)≠h(Y)이면 반드시 X≠Y 이다. 3. X≠Y이면 h(X)≠h(Y)인 것이 가장 이상적이다. 4. X≠Y이면 h(X.. 액세스 방식 Seq Scan 방식 ▪ Seq Scan은 테이블을 Full Scan 하면서 레코드를 읽는 방식이다. ▪ 인덱스가 존재하지 않거나, 인덱스가 존재하더라도 읽어야 할 범위가 넓은 경우에 선택한다. Index Scan 방식 ▪ Index Scan은 인덱스 Leaf 블록에 저장된 키를 이용해서 테이블 레코드를 액세스하는 방식이다. ▪ 인덱스 키 순서대로 출력된다. ▪ 레코드 정렬 상태에 따라서 테이블 블록 액세스 횟수가 크게 차이 난다. Bitmap Index Scan 방식 ▪ 테이블 랜덤 액세스 횟수를 줄이기 위해 고안된 방식이다. ▪ Index Scan 방식과 Bitmap Index Scan 방식을 결정하는 기준은 인덱스 칼럼의 Correlation 값이다. ▪ Correlation이란 인덱스 칼럼에 대한.. Explain Explain 사용 모드 ▪ Explain은 크게 2가지 모드로 사용할 수 있다. 1) 예측 모드: 실제 수행은 하지 않고 예상 실행 계획을 제공한다. 2) 실행 모드: 실제 수행을 한 후에 실행 계획, 수행 시간, IO 블록 수를 제공한다. ▪ 예측 모드 사용법 explain select * from t2; QUERY PLAN -------------------------------------------------------------- Seq Scan on t2 (cost=0.00..18334.00 rows=1000000 width=37) • 쿼리 앞에 explain 키워드만 추가하면 된다. • 통계 정보를 참고해서 COST, 예상 ROWS, 칼럼 길이 정보를 제공한다. ▪ 실행 모드 사용법 expl.. COST 계산에 이용되는 파라미터 / 통계 정보 IO 비용 계산을 위한 파라미터 ▪ seq_page_cost ✓ Seq Scan 방식으로 1 블록을 읽는 비용 ▪ random_page_cost ✓ Index Scan 방식으로 1 블록을 읽는 비용 ✓ 인덱스 Root 블록과 Branch 블록을 제외 CPU 비용 계산을 위한 파라미터 ▪ cpu_tuple_cost ✓ Seq Scan 수행 시에 1개 레코드를 액세스하는 비용 ▪ cpu_index_tuple_cost ✓ Index Scan 수행 시에 1개 레코드를 액세스하는 비용 ▪ cpu_operator_cost ✓ 레코드 1개를 필터 처리하는 비용 Seq Scan 비용 계산 ✓ 매우 단순한 방식으로 계산함 COST= SELECT relpages * current_setting('seq_page_cost'.. 이전 1 2 3 4 5 ··· 11 다음
