Ruben Fiszel 8912e21d15 perf(monitor): vacuum job_perms/job_result_stream right after each orphan sweep (#9753) ...

A customer's top-load query was the job_perms orphan sweep (cleanup_job_perms_orphaned:
6.9s mean, 41s max). The cost is discovery, not deletion (~2.1ms per row deleted): the
NOT EXISTS anti-join seq-scans the whole job_perms heap to find a few orphans, and that
scan tracks the heap's physical size. job_perms / job_result_stream_v2 get one row per job
and are drained only by these per-cycle sweeps, so they churn hard — but the bulk
vacuuming_tables() runs only ~hourly, so dead tuples bloat the heap between bulk vacuums.

Reclaim right after each sweep instead: VACUUM (SKIP_LOCKED) the swept table when it
deleted rows. Plain VACUUM (not FULL) takes only SHARE UPDATE EXCLUSIVE so concurrent job
creates/reads proceed; the visibility map skips unchanged pages so repeated runs are cheap;
SKIP_LOCKED means HA replicas don't pile up (one vacuums, the rest skip). Benchmarked ~7x:
a bloated 268MB job_perms heap swept in 35ms vs 5ms vacuumed. Chosen over an autovacuum
reloptions migration so the behavior is explicit and lives with the sweep it pairs with.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-24 10:20:53 +02:00

..

cgroups.rs

fix: improve OOM killer observability for debugging pod-level kills (#8398)

2026-03-17 00:49:21 +00:00

db_connect.rs

fix(operator): refresh IAM RDS / Entra ID tokens in operator process (#9141)

2026-05-13 06:38:57 +00:00

ee_oss.rs

feat: export audit logs to a dedicated object store folder (#9207)

2026-05-19 14:43:54 +00:00

main.rs

fix: prevent silent audit-partition outage via monitor watchdog + alert (#9729)

2026-06-23 10:13:29 +02:00

monitor.rs

perf(monitor): vacuum job_perms/job_result_stream right after each orphan sweep (#9753)

2026-06-24 10:20:53 +02:00