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?  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Can't we give better table bloat stats easily?
Следующее
От: tara@anne.cat
Дата:
Сообщение: [PATCH] minor doc fix for create-role