feat: rewrite simple to prepared

[levkk]

closes #1313

[codecov]

Codecov Report

❌ Patch coverage is 76.89076% with 55 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ter/parser/rewrite/statement/simple_to_prepared.rs	82.19%	34 Missing ⚠️
...c/frontend/router/parser/rewrite/statement/plan.rs	15.38%	11 Missing ⚠️
pgdog/src/frontend/prepared_statements/mod.rs	18.18%	9 Missing ⚠️
...rc/frontend/router/parser/rewrite/statement/mod.rs	88.88%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[meskill]

is this rewrite will later lead to prepare_statement consider it's like usual Parse and cause the same global cache check later? I guess it'll be the same name anyway if we get the same query transform anyway..

[levkk]

Yeah, so Server will see this, check its cache, if it's already prepared, it will skip (drop, add_ignore('1')). If not, it will add to its local cache and send the Parse to pg.

[levkk]

Strangely I'm seeing no performance improvements from this...in fact, this branch is a bit slower than main...

[levkk]

I might kick this one down the road. It's kinda too complicated and introduces side effects:

1. We are guessing parameter data types
2. We don't support rewriting updates, deletes or inserts because it may conflict with insert splits or sharding key updates
3. the prepared statements cache story sucks: right now, this would increase the memory requirements by number of clients x number of unique statements (huge). I think that's just because my implementation sucks here (this PR specifically) and that part can be optimized, but I'm kind of losing interest in this issue for now.

[NikolayS]

I put this through a proper Forge run to understand the “no improvement / slightly slower” result. This was not a quick local pgbench sample.

Method

• Provisioned an otherwise-idle Hetzner CCX23: 4 dedicated vCPUs, 16 GiB, Ubuntu; PgDog ran natively and PostgreSQL 18.4 ran in a host-networked container.
• Pinned and built both binaries from source with the locked release profile (LTO, codegen-units=1):
  • base: 4f6faef0ab36cab0eb80ef385a7eb50c9ea33147
  • historical PR head: 05d117d3124dfce4ac4391857b8a19e172d6c6ec
• I used 05d117d because it was the last branch commit that existed when the performance comment above was posted. The PR has moved since then.
• Used the exact workload that revision's cli.sh bench invoked: pgdog/tests/pgbouncer/pgbench-parser.sql, simple protocol, 10 clients, one pgbench job, pgbench scale 10.
• Compared three isolated arms: base, historical PR with the feature off, and the same PR binary with it on. The config was otherwise identical, and I explicitly enabled simple_to_prepared for the on arm.
• Five trials per arm. Every trial started a fresh PgDog process/pool, discarded a 5-second warmup, reset pg_stat_statements, then measured for 30 seconds.
• Captured TPS/latency plus pg_stat_statements planning counters, PgDog OpenMetrics deltas, 1-second sar/pidstat streams, binary hashes/configs/logs, and separate Linux perf profiles for off/on.

Result

arm	median TPS	five-trial range
base	6,167.7	6,156.5–6,188.6
PR, feature off	6,188.1	6,179.1–6,203.9
PR, feature on	6,056.6	6,022.1–6,227.8

Feature-on was 2.12% below the same binary with it off, and 1.80% below base, by medians. The on range overlaps the controls, so Forge's strict slowdown claim is inconclusive rather than proven. But the “no reliable improvement, slightly slower median” observation does reproduce.

The mechanism is much less ambiguous:

• PostgreSQL plans/call: 1.0 → 0.0
• PostgreSQL plan time: 0.1402 ms/call → 0
• PgDog parse/rewrite time: 0.1182 → 0.2342 ms/query

So PostgreSQL is reusing the prepared statement successfully. The issue is that almost all of the ~0.140 ms saved in PostgreSQL is replaced by ~0.116 ms of extra measured PgDog AST/rewrite/deparse work, before counting the remaining protocol/cache/message overhead.

The perf profiles show the CPU work moving tiers:

arm	PostgreSQL share of sampled cycles	PgDog worker share
off	59.09%	36.76%
on	23.71%	69.05%

Feature-on-specific hot symbols include literal replacement, deparse routines, AST allocation, vector/message cloning, and hashing. This lines up with the implementation: simple queries deliberately bypass the AST cache; each request transforms literals and deparses the statement; the historical implementation takes a global prepared-cache write; and it builds a Parse/Describe/Bind/Execute/Sync sequence on every request.

One useful control: a later branch commit (427d9f7) on pgbench's cheap built-in -S point lookup was 32.25% faster with the feature enabled. In that workload, the added PgDog parse/rewrite cost was only ~0.0038 ms/query while saved PostgreSQL planning was ~0.0222 ms/call. So this is workload- and revision-sensitive, not “prepared statements never help.”

My read: the idea works and the server-side mechanism is proven, but for the historical parser-stress workload the spike mostly moves planning CPU from PostgreSQL into PgDog and adds enough cache/protocol work to erase the gain.

I kept the complete Forge run artifacts, raw measurements, system streams, and perf data locally if we want to turn this into a committed regression case.

[levkk]

Cool. So I would maybe use this as a "we can't enable prepared statements" but we need to because of X. Not sure what X is though.