Hi Andreas, >I would suggest run only autovacuum, and with time you will see a not >more growing table. There is no need for vacuum full.
So new record, when will be pg_bulkloaded, will replace "marked-free" location? Thank you! Francesco ________________________________________ Da: pgsql-general-ow...@postgresql.org [pgsql-general-ow...@postgresql.org] per conto di Andreas Kretschmer [andr...@a-kretschmer.de] Inviato: lunedì 20 giugno 2016 11.37 A: pgsql-general@postgresql.org Oggetto: Re: [GENERAL] Vacuum full: alternatives? Am 20.06.2016 um 11:18 schrieb Job: > 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. > autovaccum marks space as free, but don't give the space back to os. I would suggest run only autovacuum, and with time you will see a not more growing table. There is no need for vacuum full. Andreas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
