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

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: Can't we give better table bloat stats easily?
Дата
Msg-id
20190817005912.duqhzpt2v4z2uqbj@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
Can't we give better table bloat stats easily? Greg Stark <stark@mit.edu>
Re: Can't we give better table bloat stats easily? Andres Freund <andres@anarazel.de>
Re: Can't we give better table bloat stats easily? Masahiko Sawada <sawada.mshk@gmail.com>
Re: Can't we give better table bloat stats easily? Jeff Janes <jeff.janes@gmail.com>
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


В списке pgsql-hackers по дате отправления
От: Greg Stark
Дата:
От: tara@anne.cat
Дата:
FAQ