Re: Sudden increase in n_dead_tup with no corresponding insert/update/delete

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Matthew Tice <mjtice(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Sudden increase in n_dead_tup with no corresponding insert/update/delete
Date: 2025-06-04 00:23:40
Message-ID: CAApHDvpcoOPq1JF_-jvNzuYigDQ_mJsXMaOjyux0agaabO3YUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 4 Jun 2025 at 07:22, Matthew Tice <mjtice(at)gmail(dot)com> wrote:
> Tue 03 Jun 2025 07:13:11 PM UTC (every 1s)
> n_dead_tup | 5038
> autoanalyze_count | 3078

> Tue 03 Jun 2025 07:13:12 PM UTC (every 1s)
> n_dead_tup | 1290579
> autoanalyze_count | 3079

> I don't understand where this large increase is coming from when there are no corresponding inserts, updates, or deletes (at the magnitude). This entire process repeats itself and, as mentioned, the same thing is happening on other observed tables.

I imagine it's from the auto-analyze that ran. Analyze will try to
estimate the live and dead rows, but since analyze only samples some
blocks, it may come up with something that's not too accurate if the
blocks it happened to sample don't contain similar percentages of dead
rows than the entire table.

See [1].

David

[1] https://github.com/postgres/postgres/blob/REL_15_STABLE/src/backend/commands/analyze.c#L1318

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dominique Devienne 2025-06-04 12:23:17 LOCALE C.UTF-8 on EDB Windows v17 server
Previous Message Ray O'Donnell 2025-06-03 20:08:48 Re: Combining scalar and row types in RETURNING