analyzer_compatibility_* 세션 설정
analyzer_compatibility_* 세션 설정
이 설정들은 ClickHouse의 새 분석기(analyzer)와 구버전 분석기 간의 동작 차이를 조정해요. 기존에 작성된 쿼리가 새 분석기에서도 동일하게 작동하도록 돕는 호환성 설정이에요. ClickHouse 소스 코드에서 자동으로 생성된 세션 설정 문서예요.
출처: 문서
본문
이 설정들은 system.settings에서 사용할 수 있으며 소스 코드에서 자동으로 생성돼요.
analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested
nested에 복합 식별자를 추가하는 것을 허용해요. 쿼리 결과를 바꾸기 때문에 호환성 설정이에요. 비활성화되면 SELECT a.b.c FROM table ARRAY JOIN a가 작동하지 않고, SELECT a FROM table은 Nested a 결과에 a.b.c 열을 포함하지 않아요.
analyzer_compatibility_allow_non_aggregate_in_having
활성화하면 분석기가 NOT_AN_AGGREGATE를 발생시키는 대신 HAVING에서 비집계(non-aggregate) AND-결합을 WHERE로 옮기는 구버전 동작을 모방해요. 표준 준수 거부가 기본값이며, v24.3 이전 ClickHouse가 사용하던 쿼리 분석에서 조용히 허용되던 쿼리에 대한 마이그레이션 지원이에요. 집계, grouping, 또는 비결정적 함수를 포함하는 결합은 HAVING에 남아요. 어떤 결합에 창 함수나 상태 저장 함수(예: rowNumberInBlock)가 포함되면 전체 HAVING에 대해 재작성이 비활성화되어 구버전 PredicateExpressionsOptimizer 동작과 일치해요. GROUP BY가 WITH CUBE, WITH ROLLUP, WITH TOTALS 또는 GROUPING SETS를 사용할 때도 이 설정은 무시돼요.
analyzer_compatibility_apply_final_to_all_joined_tables
26.6 이전 버전의 동작을 복원해요. 그 버전에서는 JOIN의 가장 왼쪽 테이블에 지정된 FINAL 한정자가 다른 모든 조인 테이블에도 잘못 적용되었어요(FINAL을 지원하는 엔진, 예: ReplacingMergeTree). 기본적으로 FINAL은 작성된 테이블에만 적용돼요. 구버전 동작에 의존하는 쿼리와의 호환을 위해 활성화할 수 있어요. 권장되는 해결책은 FINAL이 필요한 모든 테이블에 명시적으로 작성하는 것이에요.
가능한 값:
- 0 -
FINAL을 지정된 테이블에만 적용. - 1 -
JOIN의 가장 왼쪽 테이블의FINAL을 모든 조인 테이블에 적용.
analyzer_compatibility_join_using_top_level_identifier
JOIN USING의 식별자를 프로젝션에서 해석하도록 강제해요(예: SELECT a + 1 AS b FROM t1 JOIN t2 USING (b)에서 조인은 t1.b = t2.b가 아니라 t1.a + 1 = t2.b로 수행돼요). SELECT 목록 안의 하위 표현식에 정의된 별칭도 고려돼요(예: SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b)에서 조인은 t1.a + 1 = t2.b로 수행돼요). 일치하는 별칭이 최상위 별칭이 아니라 SELECT 목록 안의 하위 표현식에 정의된 경우, 쿼리에 대해 병렬 복제본이 비활성화돼요. 원격 서버(Distributed 테이블, remote 테이블 함수)로 보내지는 쿼리의 경우, 식별자가 원격 서버에서 전혀 해석될 수 없을 때만 예외로 거부돼요. 별칭이 왼쪽 테이블의 실제 열을 가리는 경우 원격 서버는 그 열로 조인하므로 결과가 로컬 실행과 다를 수 있어요.
analyzer_compatibility_multiple_joins_qualify_column_names
활성화하고 쿼리의 FROM 절에 JOIN이 두 개 이상 포함되면(쉼표로 구분된 테이블도 포함, ARRAY JOIN은 제외), 분석기는 결과 열 이름을 구버전 분석기의 multiple-joins 재작성 방식대로 지정해요:
*,<table>.*또는COLUMNS('<regexp>')확장으로 생성된 열은<alias-or-table>.<column>형태의 이름을 얻어요(한정자는 테이블 표현식의 별칭이 있으면 그 별칭, 아니면 데이터베이스가 없는 테이블 이름, 아니면 CTE 이름이에요. 별칭이 없는 조인 서브쿼리의 열은 한정되지 않은 채 남아요). 두 가지 열은 조인에 속하므로 단일 테이블 표현식에 속하지 않기 때문에 이름 그대로 유지돼요:ARRAY JOIN으로 생성된 열과JOIN ... USING으로 병합된 키. 따라서SELECT ll.arr나SELECT ll.k같은 외부 참조는 이 두 형태에서 해석되지 않아요.- 식별자 목록 형태
COLUMNS(col1, col2)는 매처 확장이 아니에요. 각 열은 식별자가 작성된 대로 정확히 이름을 유지해요. 따라서COLUMNS(x)는x를,COLUMNS(a.x)는a.x를 생성해요. SELECT목록의 별칭 없는 열 참조는 작성된 대로 정확히 이름을 유지해요(예:SELECT a.x는x가 명확해도a.x라는 열 이름을 생성해요).
이렇게 하면 한정된 이름으로 그런 열을 참조하는 외부 쿼리가 작동해요. 예:
SELECT ll.Date FROM (SELECT * FROM t AS ll LEFT JOIN t1 ON ll.k = t1.k LEFT JOIN t2 ON ll.k = t2.k);
analyzer_compatibility_prefer_alias_over_subcolumn
b.id 같은 다중 부분 식별자가 b라는 별칭의 테이블의 id 열을 가리킬 수도 있고 어떤 다른 열의 Tuple 하위 열 b.id를 가리킬 수도 있을 때, 별칭 접두사 해석(즉 b의 id 열)을 선호해요. 기본적으로 분석기는 하위 열을 선호해요. 구버전 분석기의 해석과 일치시키려면 활성화해요.