In response to "Mark Steben" <msteben@xxxxxxxxxxxxxxx>: > > I know what Vacuum full and truncate are supposed to do. Then why do you keep doing the vacuum full? Doesn't really make sense as a maintenance strategy. > 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 would expect so as well. You may want to mention which version of PostgreSQL you are using, because it sounds like a bug. If it's an old version, you probably need to upgrade. If it's a recent version and you can reproduce this behaviour, you probably need to approach this like a bug report. > > I've attached my original memo to the bottom. > > > > -----Original Message----- > From: pgsql-performance-owner@xxxxxxxxxxxxxx > [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Chris > Sent: Tuesday, March 18, 2008 9:11 PM > To: Mark Steben > Cc: pgsql-performance@xxxxxxxxxxxxxx > Subject: Re: 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@xxxxxxxxxxxxxx) > 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. > > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@xxxxxxxxxxxxxxxxxxxxxxx Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
