Feedback-ID: ia2694551:Fastmail
Date: Mon, 12 Aug 2024 11:48:44 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Sathish Reddy <sathishreddy.postgresql@gmail.com>
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: Pg_repack
Message-ID: <202408121548.x5qz5npcikiw@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+M9Y+B03KvHX2qUfvepv6_u72V7b-_zR_=SnMueBrG5xQ34Jw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202408121548.x5qz5npcikiw%40alvherre.pgsql>
Precedence: bulk

On 2024-Aug-12, Sathish Reddy wrote:

> Hi
>   We have configure pg_repack on database.when we ran pg_repak it is using
> temporary table on repack once repack done it is going to swap temporary
> table to original .on these case it is genarate huse wal files and it
> getting size increase be end .

>     We need help on these instead of using temporary table can we use unlog
> table on reduce these wal case.

I bet you'll find that pg_squeeze gives you better characteristics on
those aspects.  In any case, it's better if you can find a way to avoid
running either of these tools in a regular manner, and instead treat
them as if they were an emergency solution only, and rely on a better
configured autovacuum to avoid having to schedule them regularly.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/