필터가 1% 행만 통과하는 분석 쿼리에서 columnar vectorized execution이 어떤 데이터 이동을 줄이나요?

먼저 columnar format이 제공하는 열/page 저장과, reader/operator가 제공하는 selection vector 및 late materialization을 구분하겠습니다. 엔진이 이 전략을 지원한다면 100,000행 batch에서 filter 열을 읽어 1,000행의 위치를 mask나 index 목록으로 만들고, 넓은 payload 열은 그 위치에서만 materialize할 수 있습니다. 1,000개 위치를 4바이트 index로 표현하는 설명 모델은 1,000×4=4,000 bytes입니다. 이는 format이 자동으로 보장하는 결과가 아닙니다.

실제 trace는 filter column page read → predicate 평가 → selection 생성 → projection column read → 다음 operator 전달 순서로 기록합니다. row-group/page 단위 저장에서는 1%만 통과해도 filter가 있는 page 전체를 읽고 decode해야 할 수 있습니다. selection이 같은 page의 payload를 줄이는 것은 가능하지만, 다음 join이나 UDF가 selection을 받지 못하면 다시 dense row를 조립하는 비용이 생깁니다. 따라서 “1%니까 디스크에서 1%만 읽는다”고 말하지 않습니다.

선택률이 50%면 bitset 또는 dense mask가 단순할 수 있고, 99%면 sparse index보다 전체 vector를 전달하는 편이 나을 수 있습니다. 관측 항목은 filter/page bytes, decoded values, selection 표현 크기, projection materialize bytes, operator CPU, first-result와 p99입니다. Parquet source는 encoding과 page 구조를 설명하지만 late materialization의 존재를 정하지 않으므로, 실제 engine plan이나 operator trace에서 지원 여부를 확인하겠습니다.