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.
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 |