Re: Can't we give better table bloat stats easily?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Can't we give better table bloat stats easily?
Date: 2019-08-17 00:59:12
Message-ID: 20190817005912.duqhzpt2v4z2uqbj@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-08-16 20:39:21 -0400, Greg Stark wrote:
> But isn't this all just silliiness these days? We could actually sum up the
> space recorded in the fsm and get a much more trustworthy number in
> milliseconds.

You mean like pgstattuple_approx()?

https://www.postgresql.org/docs/current/pgstattuple.html

Or something different?

> I rigged up a quick proof of concept and the code seems super simple and
> quick. There's one or two tables where the number is a bit suspect and
> there's no fsm if vacuum hasn't run but that seems pretty small potatoes
> for such a huge help in reducing user pain.

Hard to comment on what you propose, without more details. But note that
you can't just look at the FSM, because in a lot of workloads it is
often hugely out of date. And fairly obviously it doesn't provide you
with information about how much space is currently occupied by dead
tuples. What pgstattuple_approx does is to use the FSM for blocks that
are all-visible, and look at the page otherwise.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tara 2019-08-17 04:17:07 [PATCH] minor doc fix for create-role
Previous Message Greg Stark 2019-08-17 00:39:21 Can't we give better table bloat stats easily?