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
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? |