Re: pg_repack in cluster - Mailing list pgsql-general

From Adrian Klaver
Subject Re: pg_repack in cluster
Date
Msg-id 397d08e3-de58-5f8b-271b-6b1e2bacb4ad@aklaver.com
Whole thread Raw
In response to Re: pg_repack in cluster  (dagamier <zayasj1@yahoo.com>)
List pgsql-general
On 1/13/20 7:41 AM, dagamier wrote:
> Can't afford the downtime of a "vaccuum full" and the autovacuum process is
> not cleaning up all the dead space tied up by the database. pg_repack works
> great on my test database in reclaiming disk space (in my tests I got back
> 46% of my disk space back) due to all the deletions that happen in our
> tables. I think that some of the issues are the fact that some of these
> tables are quite large and won't allow for an autovacuum to clean up as well
> as it should. pg_repack allows me to essentially do a "vacuum full" in
> online mode (I thought I read it also rebuilds the indexes as well) and this
> would greatly increase our overall performance on our systems.

I believe more information is needed to come up with an answer:

1) What version of Postgres?

2) What replication are you using logical or binary?

3) Is the space tied up needed by the OS or other programs?
Otherwise VACUUM will mark it as reusable by the database.

4) What are the size of the tables and the deletion churn rate?




-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Marcin Barczyński
Date:
Subject: No partition pruning when initializing query plan with LATERAL JOINand aggregates
Next
From: Rushikesh socha
Date:
Subject: pg_stat_statements extension