1P by neo 9달전 | favorite | 댓글 1개

PostgreSQL 16 쿼리 플래너의 새로운 기능

  • PostgreSQL 16은 쿼리 플래너에 많은 개선을 도입하여 많은 SQL 쿼리들이 이전 버전보다 더 빠르게 실행됨.
  • PG16 릴리스 노트에서 이러한 플래너 개선 사항을 볼 수 있지만, PostgreSQL 릴리스마다 변경 사항이 많아 각 변경 사항에 대한 자세한 설명을 제공하기 어려움.
  • 이 블로그 포스트에서는 PostgreSQL 16 쿼리 플래너에서 이루어진 10가지 개선 사항에 대한 깊은 분석을 제공하며, PG15와 PG16 플래너 출력의 비교와 함께 변경된 사항에 대한 예제를 제공함.

PostgreSQL 16 쿼리 플래너의 10가지 개선 사항

  • 증분 정렬: PostgreSQL 13에서 처음 도입된 증분 정렬은 일부 결과 집합이 이미 하나 이상의 선행 열로 정렬되어 있는 경우 이를 활용하여 나머지 열에 대해서만 정렬을 수행함.
  • 정렬된 데이터를 사용하는 집계: PostgreSQL 16 쿼리 플래너는 이제 집계 노드에 정렬된 순서대로 행을 공급하는 계획을 형성하려고 시도함.
  • 메모이제이션: PostgreSQL 14에서 처음 도입된 메모이제이션 계획 노드는 중복된 값 조회를 피하기 위해 캐시 계층으로 작동함.
  • 안티 조인: PostgreSQL 16은 안티 조인을 수행할 때 더 작은 테이블을 해시할 수 있도록 함.
  • 병렬 해시 조인: PostgreSQL 16은 FULL 및 RIGHT 조인 유형에 대한 병렬 해시 조인을 지원함.
  • 윈도우 함수 최적화: PostgreSQL 16은 ROWS 모드를 사용할 때 RANGE 모드보다 빠른 윈도우 함수를 사용할 수 있도록 함.
  • 항상 증가하는 윈도우 함수 최적화: PostgreSQL 16은 ntile(), cume_dist(), percent_rank() 등의 윈도우 함수에 대한 최적화를 확장함.
  • 파티션 테이블에서의 조인 제거: PostgreSQL 16은 파티션 테이블에서 LEFT JOIN 제거 최적화를 허용함.
  • DISTINCT 쿼리에 대한 Limit 사용: PostgreSQL 16 쿼리 플래너는 모든 행이 동일한 값을 포함하고 있음을 감지할 수 있을 때 결과의 중복 제거를 위한 계획 노드를 포함하지 않음.
  • Merge Join에 대한 규칙 완화: PostgreSQL 16 쿼리 플래너는 Merge Join을 고려할 때 행의 순서가 정확히 일치하는 대신 최소한 하나의 선행 열이 올바르게 정렬되어 있는지 확인함.

GN⁺의 의견

  • PostgreSQL 16의 쿼리 플래너 개선은 데이터베이스 성능 향상에 중요한 역할을 함. 특히 증분 정렬과 메모이제이션 같은 기능은 복잡한 쿼리를 더 효율적으로 실행할 수 있게 해줌.
  • 이러한 개선 사항들은 PostgreSQL을 사용하는 개발자와 데이터베이스 관리자에게 매우 유용할 것이며, 특히 대규모 데이터를 다루는 시스템에서 성능 개선을 체감할 수 있을 것임.
  • PostgreSQL 커뮤니티의 지속적인 혁신과 개선 노력은 오픈 소스 데이터베이스 기술의 발전을 이끌고 있으며, 이는 사용자와 기업에게 더 나은 데이터 관리 솔루션을 제공함.
Hacker News 의견
  • 포스트그레스(Postgres) 쿼리 플래너가 실행 중간에 쿼리를 재계획할 수 있으면 좋겠다는 의견이 있음. 데이터 분포에 대한 정보가 부족해 비효율적인 쿼리 계획이 수립되고, 이로 인해 실행 시간에 큰 영향을 미칠 수 있음. 쿼리가 예상보다 느리게 진행될 경우 현재 진행 정보를 바탕으로 쿼리를 재계획하는 기능이 필요함. 그러나 포스트그레스는 스트리밍 쿼리를 지원하기 때문에, 실행 중간에 계획을 변경하는 것은 상당한 인프라 변경을 요구함.
  • 쿼리 시각화 도구로 explain.dalibo.comwww.pgexplain.dev를 사용한다는 사용자가 있음. 두 도구 모두 유사한 출력 결과를 제공함.
  • 쿼리 플래너 개선은 데이터베이스에서 중요한 부분이지만, 주로 원하는 대로 작동하지 않을 때 눈에 띈다는 의견이 있음. 최신 포스트그레스 버전의 JIT(Just-In-Time) 컴파일러는 사용 시점의 휴리스틱이 강건하지 않아 보이며, 작은 데이터에 대해 느려질 수 있어 JIT를 비활성화하는 것이 좋다는 경험을 공유함.
  • 실제 쿼리에서 얼마나 자주 변경사항이 효과가 있는지, 특히 "가능할 때 DISTINCT 대신 Limit을 사용"하는 변경이 실제로 적용되는 경우가 있는지 궁금하다는 의견이 있음. 포스트그레스 개발자들이 이에 대한 정보를 가지고 있는지에 대한 질문이 있음.
  • 애플리케이션 테스팅을 위한 "엄격 모드"가 있으면 좋겠다는 의견이 있음. 이 모드에서는 쿼리를 개선할 수 있는 인덱스가 없을 경우 오류를 반환하며, "CREATE INDICES FOR <sql>" 명령어를 통해 필요한 인덱스를 생성할 수 있음. 개발 및 대화형 사용을 위한 자동 인덱스 생성 모드도 제안됨.
  • 한 사용자의 친구가 중소기업을 위한 마이크로소프트 DBA로 일하며, 포스트그레스로는 심각한 작업을 할 수 없다고 주장함. 포스트그레스에 쿼리 플래너가 없다는 사실에 놀랐다고 하나, 이는 잘못된 정보임. MSSQL이 포스트그레스보다 더 큰 규모의 작업을 처리할 수 있다는 주장에 대한 신빙성에 대한 질문이 있음.
  • 포스트그레스가 힌트(hints)를 구현하지 않는 이유에 대한 의문이 제기됨.
  • Citus Data가 발표한 기능이 왜 postgresql.org가 아닌 다른 곳에서 나왔는지, 유료 기능인지 아니면 오픈 소스 추가 기능인지에 대한 질문이 있음.
  • 포스트그레스가 IS NOT DISTINCT FROM 쿼리를 가속화하기 위해 인덱스를 사용할 수 있는 시점에 대한 질문이 있음.
  • 한 댓글이 신고되어 플래그(flagged) 처리됨.