optimize_trivial_approximate_count_query
이러한 추정을 지원하는 저장소(예: EmbeddedRocksDB)의 단순 count 최적화에는 근사값을 사용합니다. 가능한 값:- 0 — 최적화가 비활성화됩니다.
- 1 — 최적화가 활성화됩니다.
optimize_trivial_count_query
MergeTree의 메타데이터를 사용해 단순한SELECT count() FROM table 쿼리를 최적화하는 기능을 활성화하거나 비활성화합니다. 행 수준 보안(row-level security)을 사용해야 하는 경우 이 설정을 비활성화하십시오.
가능한 값:
- 0 — 최적화가 비활성화됩니다.
- 1 — 최적화가 활성화됩니다.
optimize_trivial_count_with_sparsity_filter
optimize_trivial_count_query 최적화를SELECT count() FROM t WHERE col <op> const 형태의 쿼리까지 확장합니다. 여기서 <op> const는
행을 col의 기본값과 비기본값으로 정확히 구분해야 합니다. 그러면 count 값은
MergeTree가 이미 serialization.json에 유지하는 컬럼별 num_defaults / num_rows
카운터에서 데이터 스캔 없이 바로 처리됩니다.
인식되는 패턴:
Int*/UInt*,String/FixedString,Date/DateTime/DateTime64,Decimal*,UUID,IPv4/IPv6타입의col = default(col)/col != default(col).Nullable컬럼의IS NULL/IS NOT NULL.String컬럼의empty(col)/notEmpty(col).Bool컬럼의col = true/col != true.- 부호 없는 정수 컬럼의
col > 0,col >= 1,col < 1,col <= 0. Int*,UInt*,Bool컬럼의 단독col/NOT col(truthy 검사).
Float*, Enum*, Nullable, LowCardinality,
또는 복합 타입(Tuple, Array, Map, …)에는 적용되지 않습니다. 이러한 타입에서는 count가
일반 스캔 경로로 처리됩니다.
이 기능이 적용되려면 파트별 num_defaults 카운터가 정확해야 합니다. 대상 테이블에서
삽입과 머지 전에 MergeTree 테이블 설정 compute_exact_num_defaults_for_sparse_columns을
활성화하십시오. 이 설정 없이 기록된 파트는 재작성에서 자동으로 제외되므로,
optimize_trivial_count_with_sparsity_filter만 활성화해서는 충분하지 않습니다.
Nullable 컬럼의 IS NULL / IS NOT NULL 패턴의 경우, 해당 컬럼에는 추가로
serialization.json에 num_defaults 항목이 있어야 합니다. 이는 삽입 /
머지 시점에 MergeTree 테이블 설정 nullable_serialization_version이 allow_sparse로 설정된 경우에만 생성됩니다.
기본값 basic에서는 Nullable 컬럼에 컬럼별 항목이 생성되지 않으므로
이 최적화는 자동으로 적용되지 않습니다.
가능한 값:
- 0 — 최적화가 비활성화됩니다.
- 1 — 최적화가 활성화됩니다.
optimize_trivial_group_by_limit_query
집계 대상을 최대n + offset개의 고유 키로 제한하여 단순(trivial) 쿼리 SELECT ... FROM table GROUP BY key_expr LIMIT n(HAVING/ORDER BY/QUALIFY/LIMIT BY/DISTINCT/윈도우 절과 GROUP BY 수정자가 없는 경우)을 최적화하는 기능을 활성화하거나 비활성화합니다.
프로젝션에 집계 함수가 없으면 max_rows_to_group_by = n + offset과 group_by_overflow_mode = 'any'를 설정하는 방식으로 제한이 적용됩니다(이 형태는 분산 쿼리의 세그먼트에서도 적용됩니다). 프로젝션에 집계 함수가 있으면 서버가 전체 집계를 로컬에서 수행하는 경우에만 제한이 적용됩니다. 이때 집계 스레드 중 하나라도 제한을 초과하면 모든 스레드가 n + offset개의 키만 유지하는 하나의 공유 Set을 사용하도록 제한되므로, 반환되는 키의 집계 값은 정확하게 유지됩니다.
다음과 같은 경우에는 이 최적화가 적용되지 않습니다. 사용자가 group_by_overflow_mode를 any가 아닌 값으로 명시적으로 설정한 경우(명시적으로 지정한 throw/break 동작을 보장하기 위함), 사용자가 이미 더 작은 max_rows_to_group_by 값을 설정한 경우, 그리고 exact_rows_before_limit을 사용하는 경우(제한으로 인해 rows_before_limit_at_least가 최대 n + offset까지만 보고되기 때문)입니다.
집계 함수 형태는 동일한 쿼리에서 enable_group_by_top_k_optimization의 GROUP BY top-K 힙과 함께 사용할 수 없습니다. 힙 방식이 더 빠르므로 이 제한은 힙이 적용되지 않을 때만 사용됩니다. 즉, 힙 최적화가 비활성화된 경우, n + offset이 query_plan_max_limit_for_top_k_optimization을 초과하는 경우, max_rows_to_group_by가 설정된 경우, 또는 쿼리 계획이 직렬화되는 경우입니다.
가능한 값:
- 0 — 최적화 비활성화.
- 1 — 최적화 활성화.
optimize_trivial_insert_select
단순한 ‘INSERT INTO table SELECT … FROM TABLES’ 쿼리를 최적화합니다 이 설정을 사용할 때는max_insert_threads 설정도 명시적으로 지정하십시오. 이 최적화는 SELECT의 읽기 스레드 수를 최대 max_insert_threads개로 제한하므로 SELECT가 생성하는 블록 수가 달라집니다.
optimize_trivial_view_pushdown_to_distributed
활성화하면SELECT 목록에 컬럼 참조, *,
또는 표현식만 포함하고(윈도우 함수나 스칼라 서브쿼리는 제외), 집계, 그룹화, 정렬 또는 조인이 없는 분산 테이블 기반 뷰의 전체 외부 쿼리가
각 세그먼트로 푸시됩니다. 이를 통해 세그먼트에서 뷰의 필터와 표현식을 로컬로 적용할 수 있어 네트워크를 통해 전송되는 데이터 양이 줄어듭니다.
가능한 값:
- 0 — 최적화가 비활성화되며,
분산테이블 기반 뷰는 항상 코디네이터에서 실행됩니다. - 1 — 최적화가 활성화됩니다.