Abstract

At 50,000 inserts per second, a skewed partition key can route 40,000 of them into a single partition. That one partition throttles your entire write path while the other 199 sit idle.

This happens constantly in field telemetry. Teams partition by the column they already filter on, which in oilfield platforms usually means well_id, pad_id, or asset_id. The schema looks correct. Storage looks balanced. Then p95 write latency drifts from 8ms to 25ms over six weeks and every other metric reads healthy.

This session shows you how to find it and fix it. We run the diagnostic against a partitioned tag table, identify the hot partition by dead tuple ratio and index bloat, and then walk through two schema-level fixes. You leave with queries you can run against your own largest table today.

What you'll learn

• Why a skewed partition key does more damage than a missing index, and why it stays invisible until the damage is done

• How write concentration compounds through index page splits, WAL volume, and per-partition autovacuum that has no idea it is being starved

• How to move from value-based to time-based range partitioning, and what the migration path looks like above and below 100 million rows

• How hypertables handle chunk creation, compression, and lifecycle without external cron jobs, and what that does to WAL throughput

Can’t make it live? Register anyway and we’ll send you the recording.