|
머.... 그다지 아는것은 없지만 아는것만 몇자 적어 봅니다. 도움이 되실란지...
-- bk 님이 쓰신 글:
>> MySQL만 쓰다가 innodb를 써도 서브쿼리등 기능이 미약한거같아서
>> postgreSQL로 바꿔서 태스트해보고 있는데요..
>> 몇가지 이상한점이 있어서...
>>
>> 1. postgreSQL에는 tinyint가 없나요? int2부터 있는거같은데..
적은 공간을 차지하는 정수형 자료형을 쓰면 되겠죠
>> 2. PgSQL user 매뉴얼보면 cost,rows,width에 대해 설명이 되있는데
>> 잘 이해가 안가서..
>> cost는 데이타가 저장된 disk page fetch하는 개수라고 되있는데
>>
>> ----------------------------------------------------------
>> Sort (cost=1.23..1.23 rows=9 width=7)
>> -> Seq Scan on t2 (cost=0.00..1.09 rows=9 width=7)
>>
>> EXPLAIN
>> -----------------------------------------------------------
>>
>> 이렇게 나오면 1차로 sort하는데 1.23disk page를 스캔해서 소트한다음
>> 그걸 2차로 스캔하는데 그게 0~1.09disk page가 된다는 얘기인가요?
저도 Explain을 쭈욱 찾아 뒤지고 해봤지만 명쾌하게 이해가 가지 않습니다만... cost는 미리 정의한 자신의 하드웨어세팅값을 기초(cpu속도 디스크속도 뿐만아니라 히스토그램이나 인덱스타는 방법까지 계산해서 나온 비용이라고 보면 됩니다. 근데 이러한 세팅을 정밀하게 안해 두고 이 값을 믿으면 안되겠죠.. 기본설정값에 근거한 수치가 나오겠지만요.
rows는 전체 검색된 행수고 width는 데이터의 양과 관계있습니다. 평균 바이트 수라나......
>> 3. pgsql의 문제인거같은데
>> 인덱스가 없을때 table t2의 실행계획을 보면
>> rows가 1000이 나옵니다. 분명 9개row만 들어있는데...
>> order by no하면 69.83이라는 엄청난...
>>
>> 또 인덱스가 있어도 where절 썼는데 인덱스 사용을 안하네요..
>> (전에 mysql쓸때 인덱스를 양수로 하고 desc쓰면
>> 인덱스 안쓰는 경우가 있어서 음수로 했는데 postgreSQL은 상관없네요)
인덱스가 없을때 Rows의 량이 많이 나오는건 PostgreSQL의 Excute Plan이 예측을 할 수 없길래 그냥 나오는 거고 비용도 그만큼 늘어나 있을겜니다.
인덱스 타는것은 인덱스가 걸려있는 조건절의 컬럼이 변형을 일으키면 탈 수 없고 인덱스가 A,B,C의 세개로 걸려있는 컬럼에서 컬럼 C만을 인덱스를 타보자는 시도는 실패합니다. B만도 마찬가집니다. A나 A,B 이렇게 아니면 A,B,C이렇게 타야 한답니다.. (7.2는 어케 되었는지 아직 모름... --;;)
인덱스 이야기가 나왔으니... PostgreSQL에서 인덱스는 리버스 인덱스 해쉬인덱스도 지원하는걸로 알고 있습니다. 메뉴얼에 보면 해쉬인덱스는 해쉬인덱스를 쓰는것이 더 성능좋은 인덱스를 쓰는것인지 아직 모르겠다고 쓰여 있는걸로 기억하니.. 그냥 b-tree인덱스가 좋을것같군요.
넘 Execute Plan을 보면서 궁리하지 마시고 적절한 모델링과 적절한 조인과 적절한 인덱스를 정식으로 사용하시면 좋은 응답속도가 보장되리라... 생각합니다. 글구 이렇것이 모두 수반될때 튜닝을 해주면 금상첨화겠죠.
>>
>> mysql만 쓰다보니 쉬운거에 넘 익숙해져서...
>> 왠지 모든게 다 어렵게 느껴지는 TT;
|
