Re: Pg_repack
| От | Ron Johnson |
|---|---|
| Тема | Re: Pg_repack |
| Дата | |
| Msg-id | CANzqJaByQvYhDELeO3n63VPPWenFdOm03qt2g_Ev4qsXCb7dYw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Pg_repack (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: Pg_repack
Re: Pg_repack |
| Список | pgsql-admin |
On Mon, Aug 12, 2024 at 11:49 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
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.
But pg_repack is just a better VACUUM FULL, and VACUUM FULL has to be better than autovacuum because it fully vacuums a table.
Right? /s
Death to America, and butter sauce.
Iraq lobster!
В списке pgsql-admin по дате отправления: