PostgreSQL 9.6 성능이야기

도서 정오표

주차 계산을 잘못해서 4월말에 수정 예정인 오류 내용을 5월2주차 (5월12일) 에 반영할 예정입니다. 참고 부탁드립니다. 🙂

2017.4-26

오류내용:  오타

수정전: Auovacuum
수정후: Autovacuum

위치: 종이책(221p), 전자책(321p) – 5월12일 이후버전에서 수정예정

 

2017.4-04

오류내용:  테이블명 오류

수정전 : explain (analyze) select * from t1 where c1=1; 
수정후 : explain (analyze) select * from t2 where c1=1;

위치:  종이책(183p), 전자책(266p) – 5월12일 이후버전에서 수정예정

2017.4-04

오류내용:  set 절 누락  (아래의 Set 절 추가필요)

set enable_mergejoin=off;
set enable_hashjoin=off;

위치:  종이책(87p), 전자책(124p) – 5월12일 이후버전에서 수정예정

2017.4-03

오류내용:  code1 테이블명 오타

위치:  종이책(289p), 전자책(419p) – 5월12일 이후버전에서 수정예정

THEN INSERT INTO mp1_y201701_coe1 =>

THEN INSERT INTO mp1_y201701_code1

2017.3-28

오류내용:  pg_class 조회 결과의 테이블명 오류 (c1->s1으로 변경 필요)

위치:  종이책(54p), 전자책(75p) – 5월12일 이후버전에서 수정예정

insert into s1 select * from c1 limit 1000;

analyze s1;

select relname, relpages, relpages*8192/1024/1024 "SIZE"

from   pg_class where relname='s1';

relname | relpages | SIZE

---------+----------+------

s1     |     8250 |   64

2017.03-10

수차례 교정을 봤음에도 오류가 있습니다. (생각지도 못한 스크립트 부분에서 한 줄이 빠져있네요. ㅠㅠ)

다행히 부크크는 POD (주문제작) 방식이므로 다음 주부터 구매하시는 분들은 아래 내용이 수정된 책을 받아보실 수 있을 것 같습니다. (2, 4주차 금요일마다 수정된 내용 적용됨) 현재 구매하신 분들은 아래 내용 참고 부탁드리겠습니다.

100page – ‘Bitmap Index Scan 방식’ 테스트 환경 구축 스트립트에서 한줄이 누락되었습니다. (아래 빨간색 부분)

-- 테이블에 1,1001,2001...2,1002,2002...순으로 입력되도록 한다. 
do $$
begin
 for i in 1..1000 loop
   for j in 0..57 loop -- 누락됨 
        insert into t2 values (i+(j*1000),'dummy'); 
   end loop;
 end loop;
end$$;

테스트 환경 구성용 스크립트“에도 반영해두었습니다.

[Q&A] PostgreSQL 9.6 성능 이야기

PostgreSQL 9.6 성능 이야기 관련 Q&A 페이지입니다.  아래 페이지에 질문을 등록해주시면 최대한 빠르게 답변드리겠습니다. 감사합니다.

Q&A #3

답변 (김시연): 2017-04-12

네. 맞습니다. JPPD 실패 시의 문제점을 부각(?)시키기 위해서 Merge Join을 disable 했는데요. 그 부분이 빠져있습니다. 이 부분은 책에도 추가를 해야겠습니다. 감사합니다 🙂

참고로, Merge Join으로 수행될 경우에는 입력 값에 따라서 성능 편차가 있습니다. 예제의 경우는 빠르게 나오지만 “a.c2=999999″와 같이 뒷 부분의 값을 입력하면 느립니다.

질문: eqon19 : 2017-04-12

전자책 228페이지 아래 JPPD실패하는 경우의 예제 테스트해보니까

QUERY PLAN
————————————————————————–
Merge Join (actual rows=1 loops=1)
 Merge Cond: (t3.c1 = a.c1)
 -> GroupAggregate (actual rows=12 loops=1)
 Group Key: t3.c1
 -> Index Scan using t3_c1_indx on t3 (actual rows=25 loops=1)
 -> Materialize (actual rows=1 loops=1)
 -> Sort (actual rows=1 loops=1)
 Sort Key: a.c1
 Sort Method: quicksort Memory: 25kB
 -> Index Scan using t2_uk on t2 a (actual rows=1 loops=1)
 Index Cond: (c2 = 10)
 Planning time: 0.981 ms
 Execution time: 0.327 ms

위처럼 나오는데

set enable_mergejoin=off;
이렇게 먼저 해줘야 책과 같은 실행계획이 나오네요. 확인 부탁드려요.

 QUERY PLAN
—————————————————————————–
Hash Join (actual rows=1 loops=1)
 Hash Cond: (t3.c1 = a.c1)
 -> GroupAggregate (actual rows=2000000 loops=1)
 Group Key: t3.c1
 -> Index Scan using t3_c1_indx on t3 (actual rows=4000000 loops=1)
 -> Hash (actual rows=1 loops=1)
 Buckets: 1024 Batches: 1 Memory Usage: 9kB
 -> Index Scan using t2_uk on t2 a (actual rows=1 loops=1)
 Index Cond: (c2 = 10)
 Planning time: 0.324 ms
 Execution time: 1654.565 ms

Q&A #2

답변 (김시연): 2017-04-12

제 환경에서도 몇 차례 더 테스트를 수행해봤습니다. 제 환경에서는 책과 동일하게 In-Memory 방식의 속도가 약간 느립니다. eqon19님과는 다른 결과가 나오는건데요.

먼저, 저 처럼 In-Memory 방식이 느린 경우는 In-Memory 방식에서의 해시 충돌에 대한 부하가 Multi-Batch 방식에서의 Temp IO 부하보다 더 클 때입니다.
만일 반대의 경우라면 In-Memory 방식이 더 빠르겠죠.

그런데 eqon19님의 환경은 SSD이고, Explain 결과를 보면 제 환경보다 IO 속도가 더 빠릅니다. 즉, Temp IO의 부하가 더 적습니다. 따라서 Multi-Batch 시의
Temp IO 부하가 더 적으므로 Multi-Batch의 속도가 더 빠를 것 같지만, 결과는 오히려 In-Memory가 빠릅니다.

아마 이런 결과가 나온 이유는, 해시 테이블 검색 속도, 즉 CPU 속도가 제 환경보다 빨라서 인 것으로 보입니다.  참고로 제 PC 환경은 Intel-Core i7-6500U 2.50GHz 입니다.

질문: eqon19 : 2017-04-11

전자책 198페이지 질문 좀 드릴게요. 아래와 같이 테스트해봤는데 책과는 다르게 in-memory방식이 더 빠른건 왜일까요.. 테스트환경은 SSD를 사용하고 있는데 관계가 있을까요

postgres=# set work_mem=’1MB’;
SET
 postgres=#
 postgres=# explain (costs false, analyze, buffers)
 postgres-# select *
 postgres-# from t1 a, t2 b
 postgres-# where a.c1=b.c1;
 QUERY PLAN
———————————————————————————-
Hash Join (actual time=214.777..1924.983 rows=4000000 loops=1)
 Hash Cond: (b.c1 = a.c1)
 Buffers: shared hit=16300 read=10728 written=14, temp read=21217 written=21091
 -> Seq Scan on t2 b (actual time=0.022..312.475 rows=4000000 loops=1)
 Buffers: shared hit=14793 read=6829 written=1
 -> Hash (actual time=214.309..214.309 rows=1000000 loops=1)
 Buckets: 32768 Batches: 64 Memory Usage: 976kB
 Buffers: shared hit=1507 read=3899 written=13, temp written=4176
 -> Seq Scan on t1 a (actual time=0.006..80.531 rows=1000000 loops=1)
 Buffers: shared hit=1507 read=3899 written=13
 Planning time: 0.107 ms
 Execution time: 2082.692 ms
 (12 rows)
postgres=#
 postgres=# set work_mem=’100MB’;
SET
 postgres=#
 postgres=# explain (costs false, analyze, buffers)
 postgres-# select *
 postgres-# from t1 a, t2 b
 postgres-# where a.c1=b.c1;
 QUERY PLAN
——————————————————————————-
Hash Join (actual time=278.591..1791.172 rows=4000000 loops=1)
 Hash Cond: (b.c1 = a.c1)
 Buffers: shared hit=16240 read=10788
 -> Seq Scan on t2 b (actual time=1.078..280.867 rows=4000000 loops=1)
 Buffers: shared hit=14765 read=6857
 -> Hash (actual time=274.582..274.582 rows=1000000 loops=1)
 Buckets: 1048576 Batches: 1 Memory Usage: 54091kB
 Buffers: shared hit=1475 read=3931
 -> Seq Scan on t1 a (actual time=0.015..98.582 rows=1000000 loops=1)
 Buffers: shared hit=1475 read=3931
 Planning time: 0.140 ms
 Execution time: 1941.265 ms

Q&A #1 

답변 (김시연) : 2017-04-04


아래의 예제를 그대로 수행하면 말씀하신 것처럼 Merge Join으로 수행되는 것이 맞습니다. 현재 해당 쿼리를 가장 빠르게 수행하는 방법이 Merge Join이기 때문입니다. 그런데 설명을 위해서 제가 다른 조인 방법을 모두 off 해두었는데, 이 부분이 책에 빠져있습니다. ㅠㅠ

즉, 수행 전에

set enable_mergejoin=off;
set enable_hashjoin=off;

를 수행하고 테스트를 했는데, 이 부분이 책에 빠져있습니다. 4월2주차 출간본에는 해당 부분을 추가하도록 하겠습니다. 감사합니다. 🙂

질문:  eqon19 says:| 4월 4, 2017 (2:37 오후) 편집

질문 좀 드릴게요. 책 124페이지 맨위에 Nested Loop실행계획 부분이요. 똑같이 따라 했는데 아래처럼 Merge join으로 풀리는 이유가 뭘까요. 딱히 파라미터 바꾼게 없는것 같은데… 어떤 파라미터가 영향을 미쳤을까요.. 굳이 따지자면 테스트환경은 디스크 SSD 사용하고 있습니다만…

postgres=# explain
postgres-# select *
postgres-# from t1 a, t2 b
postgres-# where a.c1=b.c1;

QUERY PLAN
———————————————————————————–
Merge Join (cost=2.54..4.53 rows=10 width=2016)
Merge Cond: (b.c1 = a.c1)
-> Index Scan using t2_idx01 on t2 b (cost=0.28..181.28 rows=1000 width=1008)
-> Sort (cost=2.27..2.29 rows=10 width=1008)
Sort Key: a.c1
-> Seq Scan on t1 a (cost=0.00..2.10 rows=10 width=1008)

“PostgreSQL 9.6 성능 이야기” 전자책 출간 및 Yes24에서 종이책 유통이 시작되었습니다.

PostgreSQL 9.6 성능 이야기 전자책이 출간되었습니다.

전차책을 읽는 사소한 Tip


제가 출간한 전자책이 어떤 형태로 서비스되는지 궁금해서, Yes24에서 1권을 구매했습니다. 핸드폰과 아이패드는 Yes24앱으로, PC는 PC용 크레마로 읽을 수 있습니다.

핸드폰과 아이패드는 앱을 이용하므로 TTS (Text to Speech) 를 지원합니다. TTS 기능 이용 시에는 “한영 자동 변환” 옵션을 체크하는 게 좋을 것 같습니다. 이렇게 하면 영문 단어는 원어민이 읽어주므로 리스닝 연습도 할 수 있는 부가적인 효과가 있습니다.

아이패드, PC에서는 양면보기가 가능한데, 아이패드의 경우에는 설정에서 “양면보기 시 첫페이지 여백 넣기”를 해제하고 보는게 좋습니다. 그래야 짝수 페이지가 왼쪽에 위치합니다.

종이책 외부유통


Yes24, 알라딘에 종이책 유통은 시간이 꽤 걸리네요? 이번 주면 유통 될 것 같습니다.

김시연 올림.

“PostgreSQL 9.6 성능 이야기” 전자책용 미리보기 (1~2장)입니다.

“PostgreSQL 9.6 성능 이야기” 전자책 (PDF) 출간을 위한 편집 작업을 완료했습니다. e-Pub를 통한 Yes24, 알라딘, 반디앤루니스의 입점은 대략 3월20일 전후가 될 것 같습니다.

1~2장 미리보기 파일은 아래의 링크를 누르시면 다운로드할 수 있습니다. 기존의 종이책 미리보기 용 PDF 파일보다는 훨씬 보기 편리할 것 같습니다.  🙂

전자책-미리보기(1장,2장) Download

 

전자책 출간 예정입니다.

늦어도 3월 말 이전에는 “PostgreSQL 9.6 성능 이야기” 전자책 (PDF 버전)을 출간할 수 있을 것 같습니다.

현재 ePub (Yes24, 알라딘 등의 전자책 유통사), 리디북스 (국내 전자책 유통 1위)와 유통 계약을 진행 중 중입니다 (구글북스는 신규 출판사 계약이 재개된 후에 등록 예정입니다)

따라서 조만간 대부분의 온라인 서점과 리디북스에서 전자책 구매가 가능할 것 같습니다. 전자책을 선호하시는 분께는 반가운 소식일 것 같습니다.

전자책 가격은 보통 종이책의 70%로 산정한다고 합니다. 저는 대략 63%인 17,000원으로 ISBN을 신청해뒀습니다. 유통 후 30일 동안은 홍보 기간이라고 해서 10%를 할인한다고 하니 15,300원에 구매할 수 있습니다.

작업 진행 내용 및 지금껏 몰랐던 전자책의 장점


지금 열심히 PDF 버전을 작업 중입니다. 일반 소설의 경우에는 EPUB로 작업하는 게 정석이라고 합니다. 핸드폰, 태블릿, PC 등에서 맞게 폰트 크기, 폰트 종류 등을 조절할 수 있기 때문이죠. 그런데 PDF로 잘만 작업하면 EPUB 못지않은 품질을 낼 수 있을 것 같습니다. 특히, 제 책은 그림이 70개 가까이 되므로, PDF로 편집을 잘 하는 것이 더 효과적일 것 같습니다.

이를 위해, 핸드폰, 태블릿, PC 환경에서 가장 적합한 폰트 크기를 찾는 작업을 수차례 해본 후에, 현재 14pt로 기본 폰트 크기 수정 작업 중입니다. (종이책은 9.5 pt)  그리고 여백 조절, 제목 컬러 적용, 표 컬러 및 음영 적용, 그림 크기 조정 등의 작업을 진행 중입니다. 자화자찬이긴 하지만, 제 태블릿에서 확인해보니 꽤 볼만합니다. 컬러를 입히니 디자인도 더 예쁘고, 한 페이지씩 넘겨서 보니까 집중도도 더 높아지는 것 같습니다. 🙂

이렇게 작업을 하다보니, 다음과 같은 이유에서 IT 서적은 전자책이 매우 좋은 것 같습니다.

  1. IT 서적은 몇 개의 책을 제외하면 고전이 아니다. 즉, 시대가 지나면 사라진다.
  2. IT 서적은 그림을 넣으면 매우 좋다. 하지만 일반 도서는 컬러 그림 삽입이 제한적이다. (다만, 이번에는 시간상 기존 흑백 그림을 이용했습니다)
  3. IT 서적은 검색 기능이 매우 필요하다.
  4. 기타 (독자들은 종이책보다 싼 가격으로 구매할 수 있고, 저자에게는 높은 인세가 지급된다. 이점도 무척 중요한 점이죠. :))

물론, 이런 점에도 불구하고 종이책을 선호하는 분들이 많습니다. 저 역시 며칠 전까지만 해도 그랬으니까요.  여하튼 중요한 것은 매체의 다양성뿐만 아니라 컨텐츠의 품질이겠죠. 더 좋은 내용의 책을 만들기 위해서 꾸준히 노력하겠습니다.

감사의 글


전자책 출간에 영감(?)을 주신 eqon19 님께 감사합니다.