Re: A concurrent VACUUM FULL? - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: A concurrent VACUUM FULL?
Date
Msg-id 202506301637.sz4ohwncgvkk@alvherre.pgsql
Whole thread Raw
In response to Re: A concurrent VACUUM FULL?  ("DINESH NAIR" <Dinesh_Nair@iitmpravartak.net>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring
Next
From: "David G. Johnston"
Date:
Subject: Re: Issue with custom operator in simple case