Re: pg_repack in cluster

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: dagamier <zayasj1(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: pg_repack in cluster
Date: 2020-01-13 18:36:17
Message-ID: 397d08e3-de58-5f8b-271b-6b1e2bacb4ad@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rushikesh socha 2020-01-13 19:15:21 pg_stat_statements extension
Previous Message Marcin Barczyński 2020-01-13 15:42:18 No partition pruning when initializing query plan with LATERAL JOIN and aggregates