[gedaiu]

On Lore's deployment a materialize_typed job ran its source cleanup (DELETE FROM typed_fact_sources … NOT EXISTS (…), step 1 of materialize_in_tx) for over three hours on a base of about 438,000 facts and 200,000 typed-fact sources. It held the database at its 4-CPU limit, and a second recompute of the same base waited on the advisory lock behind it.

The statement is fast when planned for its base. On a copy of that base's tables (same rows, same indexes, work_mem 16MB):

Plan	Time
Custom plan, the base's id known	2.2 s
Generic plan of the prepared statement	cancelled at 10 min

sqlx prepares statements, and after a few runs on a connection Postgres switches to a generic plan. That plan can't see how many rows t.kb_id = $1 selects. It guesses about four statements and picks a nested-loop anti-join that rescans about 356,000 materialized rows for each of the base's 200,000 sources.

materialize_in_tx now starts with SET LOCAL plan_cache_mode = force_custom_plan. It is scoped to the transaction and covers both entry points, the worker's materialize and the job's try_materialize. The new test a_recompute_plans_its_statements_for_the_base_it_is_given checks the recompute's transaction plans that way, and fails without the change; a timing test would be flaky.

Upstream: proposed on deeplethe#1298, held until the maintainer agrees the shape. Not a decision record: it's a plan fix with no behaviour change.

🤖 Generated with Claude Code

[gedaiu]

Upstream asked for a different shape, now deeplethe#1307: .persistent(false) on the whole-base statements plus s.kb_id = $1, instead of this SET LOCAL. When it merges and dev is synced into re-dev, this commit should be reverted in the same sync, so re-dev carries upstream's version only.