Re: Very slow "bloat query"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Very slow "bloat query"
Дата
Msg-id 1884331.1621004642@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Very slow "bloat query"  (Marcin Gozdalik <gozdal@gmail.com>)
Ответы Re: Very slow "bloat query"  (Marcin Gozdalik <gozdal@gmail.com>)
Список pgsql-performance
Marcin Gozdalik <gozdal@gmail.com> writes:
> I have traced the problem to the bloated `pg_class` (the irony: `pgmetrics`
> does not collect bloat on `pg_catalog`):
> `vacuum (full, analyze, verbose) pg_class;`
> ```
> INFO:  vacuuming "pg_catalog.pg_class"
> INFO:  "pg_class": found 1 removable, 7430805 nonremovable row versions in
> 158870 pages
> DETAIL:  7429943 dead row versions cannot be removed yet.

Ugh.  It's understandable that having a lot of temp-table traffic
would result in the creation of lots of dead rows in pg_class.
The question to be asking is why aren't they vacuumable?  You
must have a longstanding open transaction somewhere (perhaps
a forgotten prepared transaction?) that is holding back the
global xmin horizon.  Closing that out and then doing another
manual VACUUM FULL should help.

            regards, tom lane



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

Предыдущее
От: Marcin Gozdalik
Дата:
Сообщение: Re: Very slow "bloat query"
Следующее
От: Marcin Gozdalik
Дата:
Сообщение: Re: Very slow "bloat query"