pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
1–9 of 9 posts
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#2[flagged]
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#3> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12.
LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off right in the middle of reading.
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#4Please consider comparing pg_clickhouse to pgrust.
https://malisper.me/how-we-made-postgres-hundreds-of-times-f...
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#5Please consider comparing pg_clickhouse to pgrust. https://malisper.me/how-we-made-postgres-hundreds-of-times-f...
They're not really compatable. Your link already compares pgrust & clickhouse. A comparison would not be by using postgres_fdw from postgres to pgrust
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#6> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12. LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off rig…
LLMs have provided the uncanny valley to writing.
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#7As someone who tried doing things like condition pushdown, transpiling from one language to another, etc, this is really impressive. Correctly pushing subqueries while preserving the semantics of the original database is something I can't imagine I could've ever achieved
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#8> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12. LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off rig…
Yeah. There's some solid work in there, but it reads like an LLM without a review pass.
This paragraph has an awkward rhythm:
> Getting more into the nitty-gritty, we also closed a subsecond-precision loss when inserting timestamps over HTTP (#300), and to top it all off, a broader static-analysis pass over the codebase turned up and fixed a handful of other latent bugs (#313); these hadn't showed up in the field, but were worth closing before they could.
Even just asking Claude to apply Strunk and White makes it much easier to read:
> We also fixed a loss of subsecond precision in timestamps inserted over HTTP (#300). A static-analysis pass over the codebase turned up several other latent bugs (#313); none had surfaced in the field, but we fixed them anyway.
And its diagnosis of why the original is tricky shows an LLM is more than capable of improving readability given a couple of review passes:
> Three things make it awkward, and they pile up:
> 1. Two bits of throat-clearing. "Getting more into the nitty-gritty" and "to top it all off" both just say here comes the next thing. Neither tells you anything. Back to back, they read as filler.
> 2. Mixed tone. "Nitty-gritty" and "to top it all off" are chatty; "subsecond-precision loss" and "static-analysis pass" are dry and technical. The sentence keeps switching voice.
> 3. Too much in one sentence. Two unrelated fixes joined by a semicolon, plus a clause hanging off the second one, plus the trailing "before they could." By the end, you've lost track of what "they could" was about — the thing it points back to is thirty words behind you.
It's a shame when solid technical work gets obscured by the poor SNR of default LLM output, when clarity is only a few iterations away.
Re: pg_clickhouse v0.10: Subquery pushdown and 1000x faster TPC-H queries
#9> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12. LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off rig…
Yeah. There's some solid work in there, but it reads like an LLM without a review pass. This paragraph has an awkward rhythm: > Getting more into the nitty-gritty, we also closed a subsecond-precision loss when inserting timestamps over HTTP (#300), and to top it all off, a broader static-analysis pass over the codebase turned up and fixed a handful of other latent bugs (#313); these hadn't showed up in the field, bu…
It's a weird feeling, having my prose reviewed as if they were written by a machine. "Move the needle" is a scar from my time at Google. Nitty-gritty is an artefact of all the iteration I did on that paragraph; the original was far too technical to justify its place in a little writeup. "To top it all off" was just how I chose to set a tone of wrapping up after a list that was at least as exhausting to write as it seems to be to read. And just for the record, multiple people from my team reviewed this, so if it turns out we lack your proclivity for good English style or your journalistic rigor and standards for what's ready to publish, it wasn't for a lack of "a few iterations." I suppose it would have been good of me to give my team more time with the draft; a good chunk of what you cited was a byproduct of me hastily responding to their comments.