Search Postgresql Archives

Re: Vacuum full: alternatives?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/20/2016 03:18 AM, Job wrote:
> Hello,
> 
> we have a table with an heavy traffic of pg_bulkload and delete of records.
> The size pass, in only one day, for example for 1Gb to 4Gb and then 1Gb back.
> 
> We have important problems on size and the only way to gain free space is issueing a vacuum full <table>.
> But the operation is very slow, sometimes 2/4 hours, and table is not available for services as it is locked.
> 
> We do not delete everything at one (in this case the truncate woudl resolve the problem).
> 
> The autovacuum is not able (same for normal vacuum) to free the spaces.
> 
> Are there some suggestions or another way to manage this?

Hi Francesco,

We use pg_repack (http://reorg.github.io/pg_repack/) for a similar
workload.  It allows what amounts to an online vacuum full.  The only
caveat is that you need to have the available disk space to fully
rebuild the table in parallel.

Hope that helps.

Cheers!

	- Chris


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux