Re: Deleting schema - saving up space - PostgreSQL 9.2

From: "drum(dot)lucas(at)gmail(dot)com" <drum(dot)lucas(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Deleting schema - saving up space - PostgreSQL 9.2
Date: 2016-03-16 21:27:11
Message-ID: CAE_gQfWOru43Wbec4T1GUUFoN6NrZadaEJE=0GNuudHDvayBFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 17 March 2016 at 10:21, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Wed, Mar 16, 2016 at 1:59 PM, drum(dot)lucas(at)gmail(dot)com <
> drum(dot)lucas(at)gmail(dot)com> wrote:
>
>>
>> 1 - The problem here is that a VACUUM FULL will lock all the DB to wirte,
>> am I right? My DB is 1.7 TB, so it will take a while and the System can't
>> be offline
>>
>> 1. Migrate the files to the NFS server
>> 2. Delete the schema from the MASTER DB
>> 3. Put the slaves into read-only servers
>> 4. Run Vacuum FULL into the MASTER DB
>> 5. Once the vacuum is done, do a DUMP from the MASTER to the slaves
>> (excluding the GORFS schema of course)
>>
>>
> ​If you are removing the entire object there should be no cause to VACUUM
> FULL. A vacuum full reclaims unused space ​*within a given relation.*
>
> ​Both DROP TABLE and TRUNCATE have the effect of (near) immediately
> ​freeing up the disk spaced used by the named table and returning it to the
> operating system.
>
> ​You want to use VACUUM FULL tablename; if you remove a significant chuck
> of a table using DELETE or UPDATE and want to reclaim the spaced that was
> occupied by the older version of the ​row within "tablename".
>
> VACUUM FULL; simply does this for all tables - I'm not sure when locks are
> taken and removed. likely only the actively worked on tables are locked -
> but the I/O hit is global so targeted locking only buys you so much.
>
> David J.
>
>
>

I see..

so in your opinion a DROP SCHEMA and maybe a VACUUM (not full) would be
enough?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message otheus uibk 2016-03-16 21:40:03 Re: How to Qualifying or quantify risk of loss in asynchronous replication
Previous Message David G. Johnston 2016-03-16 21:21:28 Re: Deleting schema - saving up space - PostgreSQL 9.2