설문조사
PostgreSQL/PPAS 관련 듣고 싶은 교육은


Powered by EnterpriseDB
총 게시물 145건, 최근 0 건
   

EDB에서 partition 테이블을 프로시저에서 사용할때.

글쓴이 : 옆집아저씨 날짜 : 2019-07-23 (화) 10:20 조회 : 258
안녕하세요,
가끔 들어서 여러 정보들 얻기는 했지만, 가입하고 질문은 처음 드려봅니다.

EDB에서 partition 테이블을 프로시저에서 사용할때의 문제점이 있어서 질문드리고자 합니다.
EDB 9.4버전 사용중이고, 파티션을 아래와 같이 월단위로 생성합니다.
create table tablename (,,,) partition by list (column) (partition p_m_201901 values ('201901'));
파티션추가 : alter table tablename add partition p_m_201902 values ('201902'));
이렇게 해놓으면 일반적으로 쿼리수행시는 쿼리문조건에 사용된 값에 따라 해당파티션을 읽어오는데요,
예) select * from tablename where base_ym = '201901';  -- table_p_m_201901만 읽음

do $$ begin 쿼리...  end $$ language 'edbspl'; 로 수행할때도 해당파티션만 적절히 사용되는듯 합니다.

프로시저로,  위와 똑같은 쿼리를 수행하는 경우는 전체테이블을 다 읽는듯합니다.
데이터가 한두달만 있으면 상관없는데, 1년정도 쌓이면 문제가 심각해집니다.
지금도 한 1년치 넣어놓고 테스트해보는데, 그냥 쿼리로 수행하면 5초도 안걸리는게, 프로시저로 돌리면 한시간도 넘게 안끝나네요..(인덱스는 모든 테이블에 존재합니다.)

1)프로시저에서 파싱되는 메카니즘은 일반 쿼리수행하는것과 어떻게 다른것일까요?
2)혹시 프로시저에서도 어떤 설정을 바꿔주면 일반 쿼리에서 수행하는것처럼 작동할 수 있는것인지?
3)프로시저자체는 각각 수행하는 쿼리가 많다보니 실행계획을 알수없는데, 혹시 프로시저의 실행계획을 추적할수있는 방법이 있을지요?
 
초면에 질문이 너무 많았습니다만,, 오랫동안 궁금했었는데 어딘가 물어볼데가 마땅치 않아서 여기서 문의드려봅니다.
감사합니다.

PostgresDBA 2019-07-24 (수) 16:32
쉽지않은 문젠데 현상을 찾으셨네요.
작년에 해당문제를 발견해서 주인장이 버그 리포트했습니다
11 버전에부터 fix 가 되어 pruning 이  잘된다고합니다. 백포팅은 안준다고 하더군요

9.4 에서는 함수/프로시져를  'edbspl' 타입이 아닌 'plpgsql' 타입으로 작성하면 잘 됩니다.
물론 소스 수정이 약간 필요하겠죠
댓글주소
     
     
옆집아저씨 2019-07-24 (수) 16:53
아,, 11버전 ㅜㅜ.
음, 마이그레이션은 힘들듯하고, 로컬에서 테스트나 해봐야겠습니다.
답변 감사드려요.
댓글주소
     
     
옆집아저씨 2019-07-25 (목) 09:52
로컬DB로(9.6) 테스트해봤습니다.
프로시저를 plpgsql 로 변환해봤습니다
쿼리결과 처리하는 부분이랑 전체적인 구성이 조금씩 달라서 찾아서 모두 수정하고, 컴파일하고 수행은 되는데,,
edbspl 타입으로 수행할때랑 걸리는 시간은 별반차이가 없네요.ㅜㅜ
댓글주소
   

postgresdba.com