A detailed walkthrough of how pg_clickhouse's Foreign Data Wrapper (FDW) decides which parts of a SQL query to push down to ClickHouse versus execute locally in Postgres. Using a single realistic analytics query as a running example, the post traces seven incremental steps — from basic scan/WHERE pushdown through JOIN, GROUP BY, percentile aggregates, JSON operators, and window functions — showing how each missing translation blocked the entire grouped plan. The key insight is that pushdown is all-or-nothing at the upper-relation level: one unsupported sub-expression can force millions of rows across the wire instead of 100. The post also covers why some pushdowns get revoked when semantics don't match, and explains the FDW planning callback architecture that makes this negotiation possible.
Table of contents
The query that takes 80 ms or 4 minutes #What the FDW actually negotiates #The progression: one query, every step we've shipped #Conclusion #Sort: