Database Research & Development

  • Home
  • NoSQL
    • NoSQL
    • Cassandra
  • Databases
    • Database Theory
    • Database Designing
    • SQL Server Coding Standards
    • SQL Server
    • PostgreSQL
    • MySQL
    • Greenplum
    • Linux
  • Interviews
    • SQL Server Interviews
    • MySQL Interviews
    • SQL Puzzles
  • DBA Scripts
    • SQL Server DBA Scripts
    • PostgreSQL DBA Scripts
    • MySQL DBA Scripts
    • Greenplum DBA Scripts
  • Home
  • Blog Archives !
  • (: Laugh@dbrnd :)
  • Contact Me !
sqlserverinterviews
Home 2015 November PostgreSQL: Execute VACUUM FULL without Disk Space

PostgreSQL: Execute VACUUM FULL without Disk Space

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

How to perform VACUUM FULL without disk space?

The above question is common for all PostgreSQL DBA. This is really a very important topic that I am going to discuss in this post.

We require VACUUM and VACUUM FULL in PostgreSQL because of MVCC Architecture.
You can visit this article for MVCC:

Postgres VACUUM FULL reclaims all free space released by VACUUM by removing dead rows physically.

This method also requires extra disk space, since it writes a new copy of the table and doesn’t release the old copy until the operation is complete.

In one of our Postgres Database Server, we require VACUUM FULL on one table, and this table size is 13GB, and we don’t have enough free space on hard-disk.

I worked around this problem and created one of the best solutions to resolve this problem.

To solve this problem, we need additional storage like any other network drive or portable hard disk.
Please do not forget that VACUUM FULL requires an exclusive lock on the table so during this operation your table cannot be accessible.

Now, add new hard disk and make it as table-space.

Create a new tablespace:

1
CREATE TABLESPACE temptablespace LOCATION '/path/../';

Check your table current tablespace:

1
SELECT tablespace FROM pg_tables WHERE tablename = 'mybigtable';

If it is NULL, it has a default tablespace.

Move table to new tablespace:

1
ALTER TABLE mybigtable SET TABLESPACE temptablespace;

Perform VACUUM FULL:

1
VACUUM FULL mybigtable;

Move table to old tablespace:(moving to pg_default)

1
ALTER TABLE mybigtable SET TABLESPACE pg_default;

Drop that temp table space:

1
DROP TABLESPACE temptablespace;
Nov 22, 2015Anvesh Patel
PostgreSQL: Short note on VACUUM, VACUUM FULL and ANALYZEPostgreSQL: Script to Stop all Connections and Force to Drop the Database
Comments: 7
  1. jenny
    December 6, 2015 at 5:25 pm

    I am regular visitor, how are you everybody? Thiis post posted at this
    web page is truly pleasant.

  2. Felipe
    August 19, 2016 at 5:16 pm

    I had passed throught a situation exactly like that, a table became to big, back then I didn´t what to do, well, I end up increasing the disk where the database is allocated and THEN I executed the vaccum. Your way is better and technical.

    • Anvesh Patel
      Anvesh Patel
      August 20, 2016 at 7:41 am

      Thanks Felipe,

  3. Jasen
    August 9, 2018 at 6:43 am

    much cleaner that what I was planning to do.

  4. Karthikeyan
    September 6, 2018 at 6:14 pm

    I have a question. When we move the table to another tablespace, Internally It should clear the fragmentation. In this case why should we do vacum full on the table. I am asking the question based on my oracle exp.

    • Anvesh Patel
      Anvesh Patel
      September 7, 2018 at 11:37 am

      Nice question,
      Here, we need probably because it requires to update FSM value. But still, I am not sure and need to check PostgreSQL internal.

  5. lee r
    June 28, 2019 at 4:09 am

    Or … alloc that new TS permanently for that large table, hopefully on some fast media, or better yet, a separate channel, & include it in the backup plan.

Anvesh Patel
Anvesh Patel

Database Engineer

November 22, 2015 PostgreSQL, PostgreSQL DBA ScriptAnvesh Patel, database, database research and development, dbrnd, MVCC, plpgsql, Postgres Query, postgresql, PostgreSQL Administrator, PostgreSQL Error, PostgreSQL Programming, PostgreSQL Tips and Tricks, VACUUM, VACUUM FULL
About Me!

I'm Anvesh Patel, a Database Engineer certified by Oracle and IBM. I'm working as a Database Architect, Database Optimizer, Database Administrator, Database Developer. Providing the best articles and solutions for different problems in the best manner through my blogs is my passion. I have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technology. -- Hyderabad, India.

About DBRND !

dbrnd

This is a personal blog (www.dbrnd.com).

Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Feel free to challenge me, disagree with me, or tell me I’m completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever (abusive, profane, rude, or anonymous comments) - so keep it polite.

The content of this website is protected by copyright. No portion of this website may be copied or replicated in any form without the written consent of the website owner.

Recent Comments !
  • Anvesh Patel { Sure will do... } – May 27, 12:43 PM
  • Anvesh Patel { Great... } – May 27, 12:41 PM
  • Anvesh Patel { Great... } – May 27, 12:39 PM
  • Anvesh Patel { Great... } – May 27, 12:36 PM
  • Anvesh Patel { Great... } – May 27, 12:28 PM
  • Anvesh Patel { Great... } – May 27, 12:27 PM
  • Anvesh Patel { Great... } – May 27, 12:16 PM
  • Older »
Follow Me !
  • facebook
  • linkedin
  • twitter
  • youtube
  • google
  • flickr
© 2015 – 2019 All rights reserved. Database Research & Development (dbrnd.com)
Posting....