Re: A concurrent VACUUM FULL?

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: DINESH NAIR <Dinesh_Nair(at)iitmpravartak(dot)net>
Cc: Erik Nordström <erik(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A concurrent VACUUM FULL?
Date: 2025-06-30 16:37:53
Message-ID: 202506301637.sz4ohwncgvkk@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2025-06-30 16:52:07 Re: Issue with custom operator in simple case
Previous Message Andres Freund 2025-06-30 16:27:10 Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring