Skip site navigation (1) Skip section navigation (2)

Re: question on TRUNCATE vs VACUUM FULL

From: "Mark Steben" <msteben(at)autorevenue(dot)com>
To: "'Chris'" <dmagick(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: question on TRUNCATE vs VACUUM FULL
Date: 2008-03-19 13:22:33
Message-ID: 011e01c889c4$4a8dee30$14010a0a@dei26g028575 (view raw or flat)
Thread:
Lists: pgsql-performance
I know what Vacuum full and truncate are supposed to do.

My confusion lies in the fact that we empty table C after
Function D finishes.  There aren't any current data or records
To touch on the table. The MVCC leftovers are all purely dead
Rows that should be deleted.  Given this, I thought that 
Vacuum full and truncate should provide exactly the same result.

I've attached my original memo to the bottom.



-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Chris
Sent: Tuesday, March 18, 2008 9:11 PM
To: Mark Steben
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] question on TRUNCATE vs VACUUM FULL


> 
> So my question is this:  Shouldn't VACUUM FULL clean Table C and reclaim 
> all its space?

You've got concepts mixed up.

TRUNCATE deletes all of the data from a particular table (and works in 
all dbms's).

http://www.postgresql.org/docs/8.3/interactive/sql-truncate.html



VACUUM FULL is a postgres-specific thing which does work behind the 
scenes to clean up MVCC left-overs. It does not touch any current data 
or records in the table, it's purely behind the scenes work.

http://www.postgresql.org/docs/current/interactive/sql-vacuum.html


The two have completely different uses and nothing to do with each other 
what-so-ever.

-- 
Postgresql & php tutorials
http://www.designmagick.com/

-- 
Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
[Mark Steben] 

Table A houses info on all emails that have ever been created for the
purpose of being delivered to our end customers.

Big table.  About 23 million rows.

  Table B, the 'holding' table is populated with Table A key information via
an after trigger whenever Table A is updated or inserted to.

  Table C, the 'work' table is populated by function D from table B.  It is
configured exactly like table B.

  PLPGSQL Function D inserts a predefined number of rows from table B to
table C. For purposes of discussion, say 500.  

  Function D, after it does its thing, then deletes the 500 rows it
processed from table B, and ALL 500 rows from table C.

 

This entire process, after a sleep period of 10 seconds, repeats itself all
day.

 

After each fifth iteration of function D, we perform a VACUUM FULL on both
tables B and C. 

   Takes less than 5 seconds.

 

In terms of transaction processing:

  Table A is processed by many transactions (some read, some update), 

  Table B is processed by

-         any transaction updating or inserting to Table A via the after
trigger (insert, update)

-         Function D (insert, update, delete)

  Table C is processed ONLY by function D (insert, update, delete).  Nothing
else touches it;

    PG_LOCKS table verifies that that this table is totally free of any
transaction 

        Between iterations of function D.




In response to

Responses

pgsql-performance by date

Next:From: Bill MoranDate: 2008-03-19 13:34:50
Subject: Re: question on TRUNCATE vs VACUUM FULL
Previous:From: Laurent RaufasteDate: 2008-03-19 11:18:16
Subject: PG writes a lot to the disk

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group