clickhouse-query-best-practiceslisted

# ClickHouse Query Best Practices How to write idiomatic, readable, performant research SQL in ClickHouse — especially when crossing into PostgreSQL via the `postgresql()` table function. Complementary to `clickhouse-best-practices` (schema/insert) and `composite-types` (type mapping). This skill is about **the SQL you write to investigate**, not about table design. ## When to use - Writing or reviewing ad-hoc investigations in your project's ad-hoc SQL directory (e.g. `analyses/adhoc/` or equivalent) - Operational research SQL stored under any project research directory - Federation queries that pull from a named PostgreSQL connection (or any other `postgresql()`) into ClickHouse - Any data-quality probe that mixes ClickHouse-mirror tables with `postgresql()` calls ## When NOT to use - Schema / table design — use plugin `clickhouse-best-practices` - dbt SQL inside `models/**` (production) — use plugin `clickhouse-best-practices`; for `.yml` `description:` text + the dbt-score gate see your project's yaml-conventions documentation - Type mapping for composite Tuple types — use `composite-types` - Pure data-modeling decisions (PK ordering, partitioning) — use plugin `clickhouse-best-practices` ## Rules (read these before writing) | # | Rule | Impact | |---|------|--------| | 01 | [cte-wrap-federation](rules/01-cte-wrap-federation.md) — wrap each `postgresql()` call in a named CTE once, reference by alias | CRITICAL | | 02 | [compute-boundaries-at-runtime](rules/02-compu