Re: A concurrent VACUUM FULL?
От | Álvaro Herrera |
---|---|
Тема | Re: A concurrent VACUUM FULL? |
Дата | |
Msg-id | 202506301637.sz4ohwncgvkk@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: A concurrent VACUUM FULL? ("DINESH NAIR" <Dinesh_Nair@iitmpravartak.net>) |
Список | pgsql-hackers |
On 2025-Jun-30, DINESH NAIR wrote: > In OLTP environments will it lead to slowing of the queries or query > performance issues !!!! Sure, to some extent, but ideally you wouldn't use it in a recurring fashion but only as an emergency solution out of a really serious bloat problem (so it's not something you should have impacting your production in a recurring fashion); also, performance should improve for the system overall, comparing to the state before compacting the table. I suggest you try pg_squeeze (a single run of it in a table, not scheduled runs) and report back how the system performs for you in the period when it is executing. I expect that the impact of REPACK is going to be largely the same as that of pg_squeeze, because the implementation is very similar. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ Y una voz del caos me habló y me dijo "Sonríe y sé feliz, podría ser peor". Y sonreí. Y fui feliz. Y fue peor.
В списке pgsql-hackers по дате отправления: