--- title: Diagnosing High Cardinality Workloads in pg | daily.dev description: Ryan Booz explains how to diagnose high cardinality workloads in pg_stat_statements, where too many unique normalized queries outrun the pg_stat_statements.max... canonical: https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Diagnosing High Cardinality Workloads in pg | daily.dev og:description: Ryan Booz explains how to diagnose high cardinality workloads in pg_stat_statements, where too many unique normalized queries outrun the pg_stat_statements.max... og:url: https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx og:image: https://api.daily.dev/og/posts/uG5Fr9Nrx.png og:image:alt: Diagnosing High Cardinality Workloads in pg og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Diagnosing High Cardinality Workloads in pg **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 12 min read · 0 upvotes · 0 comments ## Summary Ryan Booz explains how to diagnose high cardinality workloads in pg_stat_statements, where too many unique normalized queries outrun the pg_stat_statements.max setting and cause useful query metrics to be deallocated. He covers where the uniqueness comes from (ORMs generating per-tenant statements, custom dynamic SQL, ad hoc reporting, AI-assisted tools, and variable-length IN lists on Postgres 17 and below), then runs a side-by-side demo using the Bluebox sample database showing 671 unique statements on Postgres 17 versus only 120 on Postgres 18 thanks to IN list normalization. Five diagnostic checks are given: know your max setting, watch how fast the table refills after a reset, monitor the deallocation counter in pg_stat_statements_info, check whether known queries go missing, and watch whether your top 10 queries by execution time churn frequently. Recommended actions include revisiting configuration settings, upgrading to Postgres 18, and working with development teams on problematic query patterns from ORMs and AI tooling. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What's the difference in pg_stat_statements behavior between Postgres 17 and Postgres 18 for IN list queries? Postgres 18 normalizes variable-length IN lists down to a single statement, while Postgres 17 and below treat each unique list of values as a separate statement. In a one-hour load test using the Bluebox sample database with identical workloads, Postgres 17 accumulated 671 unique statements in pg_stat_statements versus only 120 on Postgres 18, primarily due to this IN list normalization improvement. _Track how postgres version upgrades change query monitoring behavior with daily.dev before you migrate._ ### How do I know if pg_stat_statements is losing data I need for query tuning in Postgres? Five checks reveal a high cardinality problem: check your pg_stat_statements.max setting, see how quickly the statement table refills after a reset (under 30 minutes indicates high volume), watch whether the deallocation counter in pg_stat_statements_info keeps climbing, test whether known running queries are missing from results, and check if your top 10 queries by total execution time change frequently despite a stable workload. _Developers debugging missing query metrics can compare diagnostic approaches like these on daily.dev._ ### Why do ORMs and AI coding tools generate so many unique queries in pg_stat_statements? ORMs generate unique SQL statements per client, customer, or tenant, while AI-assisted development tools query the database with unique one-off queries as they iterate to satisfy a task, often changing the query repeatedly if the first attempt doesn't return the needed information. Custom dynamic SQL with track=all and ad hoc reporting tools add further unique statements, quickly filling pg_stat_statements beyond its capacity. _Anyone tuning database performance around AI-assisted workflows can follow this topic on daily.dev._ ## Similar posts on daily.dev - [statements to Reduce Deallocations](https://daily.dev/posts/statements-to-reduce-deallocations-ffzmb8bqj) · pganalyze · 0 upvotes · 0 comments - [pg\_stat\_statements: everything it tells you](https://daily.dev/posts/pg-stat-statements-everything-it-tells-you-tihzbjd0h) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostGIS Performance: pg\_stat\_statements and...](https://daily.dev/posts/postgis-performance-pg-stat-statements-and--nuqhs6oqe) · Crunchy Data · 2 upvotes · 0 comments - [pg\_stat\_statements: everything it can't](https://daily.dev/posts/pg-stat-statements-everything-it-can-t-7p0ewuvv6) · Planet PostgreSQL · 2 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Diagnosing High Cardinality Workloads in pg","url":"https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx"},"datePublished":"2026-08-13T02:01:29.362Z","dateModified":"2026-10-14T02:21:41.922Z","description":"Ryan Booz explains how to diagnose high cardinality workloads in pg_stat_statements, where too many unique normalized queries outrun the pg_stat_statements.max...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/69018ef3ffba177cb81ba1804f5e65a8?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/69018ef3ffba177cb81ba1804f5e65a8?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"Diagnosing High Cardinality Workloads in pg"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/diagnosing-high-cardinality-workloads-in-pg-ug5fr9nrx#faq","mainEntity":[{"@type":"Question","name":"What's the difference in pg_stat_statements behavior between Postgres 17 and Postgres 18 for IN list queries?","acceptedAnswer":{"@type":"Answer","text":"Postgres 18 normalizes variable-length IN lists down to a single statement, while Postgres 17 and below treat each unique list of values as a separate statement. In a one-hour load test using the Bluebox sample database with identical workloads, Postgres 17 accumulated 671 unique statements in pg_stat_statements versus only 120 on Postgres 18, primarily due to this IN list normalization improvement. Track how postgres version upgrades change query monitoring behavior with daily.dev before you migrate."}},{"@type":"Question","name":"How do I know if pg_stat_statements is losing data I need for query tuning in Postgres?","acceptedAnswer":{"@type":"Answer","text":"Five checks reveal a high cardinality problem: check your pg_stat_statements.max setting, see how quickly the statement table refills after a reset (under 30 minutes indicates high volume), watch whether the deallocation counter in pg_stat_statements_info keeps climbing, test whether known running queries are missing from results, and check if your top 10 queries by total execution time change frequently despite a stable workload. Developers debugging missing query metrics can compare diagnostic approaches like these on daily.dev."}},{"@type":"Question","name":"Why do ORMs and AI coding tools generate so many unique queries in pg_stat_statements?","acceptedAnswer":{"@type":"Answer","text":"ORMs generate unique SQL statements per client, customer, or tenant, while AI-assisted development tools query the database with unique one-off queries as they iterate to satisfy a task, often changing the query repeatedly if the first attempt doesn't return the needed information. Custom dynamic SQL with track=all and ad hoc reporting tools add further unique statements, quickly filling pg_stat_statements beyond its capacity. Anyone tuning database performance around AI-assisted workflows can follow this topic on daily.dev."}}]} ```