Thread: Pg_repack
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.
Thanks
Sathishreddy
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/
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!
On Aug 12, 2024, at 12:06 PM, Ron Johnson <ronljohnsonjr@gmail.com> wrote:But pg_repack is just a better VACUUM FULL, and VACUUM FULL has to be better than autovacuum because it fully vacuums a table.
No.
Vacuum — actually vacuums by removing dead tuples that are no longer needed, freezing tuples, etc. The removal of dead tuples frees space on the given page and it also truncates the fully empty pages that are located at the end of the file if it can.
Vacuum FULL — is something completely different. It rebuilds the entire table thus it coalesces all free space and by proxy does the same as vacuum (removing dead tuples that are no longer needed).
— It does this by creating a new table and then swapping in the new table when; regardless of the number of dead tuples.
Vacuum FULL should not be run on a regular basis.
On Aug 12, 2024, at 12:06 PM, Ron Johnson <ronljohnsonjr@gmail.com> wrote:But pg_repack is just a better VACUUM FULL, and VACUUM FULL has to be better than autovacuum because it fully vacuums a table.
No.
Vacuum — actually vacuums by removing dead tuples that are no longer needed, freezing tuples, etc. The removal of dead tuples frees space on the given page and it also truncates the fully empty pages that are located at the end of the file if it can.
Vacuum FULL — is something completely different. It rebuilds the entire table thus it coalesces all free space and by proxy does the same as vacuum (removing dead tuples that are no longer needed).
— It does this by creating a new table and then swapping in the new table when; regardless of the number of dead tuples.
Vacuum FULL should not be run on a regular basis.
Hi,
Pg_repack doesn’t use unlogged tables, but you can minimize WAL file size by enabling wal_compression in postgresql.conf. Additionally, you can fine-tune wal_buffers, checkpoint_timeout, and checkpoint_completion_target to better manage WAL file size.
Regards,
Muhammad Imtiaz
Pg_repack doesn’t use unlogged tables, but you can minimize WAL file size by enabling wal_compression in postgresql.conf. Additionally, you can fine-tune wal_buffers, checkpoint_timeout, and checkpoint_completion_target to better manage WAL file size.
Regards,
Muhammad Imtiaz
On Mon, Aug 12, 2024 at 4:48 PM Sathish Reddy <sathishreddy.postgresql@gmail.com> wrote:
HiWe 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.ThanksSathishreddy