Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 57E7D2E0148 for ; Tue, 18 Mar 2008 18:07:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 12026-04 for ; Tue, 18 Mar 2008 18:07:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.autorevenue.com (ip-208.178.167.106.gblx.net [208.178.167.106]) by postgresql.org (Postfix) with ESMTP id 9B4332E0145 for ; Tue, 18 Mar 2008 18:07:11 -0300 (ADT) Received: (qmail 15137 invoked from network); 18 Mar 2008 17:08:45 -0400 Received: from unknown (HELO dei26g028575) (msteben@10.10.1.20) by mail.autorevenue.com with SMTP; 18 Mar 2008 17:08:45 -0400 From: "Mark Steben" To: Subject: question on TRUNCATE vs VACUUM FULL Date: Tue, 18 Mar 2008 17:06:45 -0400 Message-ID: <00f701c8893b$f9545af0$14010a0a@dei26g028575> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01C8891A.7242BAF0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Thread-Index: AciJO/k6/Fq+E9SAQeOcab0m3MbnCg== X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/382 X-Sequence-Number: 29336 This is a multi-part message in MIME format. ------=_NextPart_000_00F8_01C8891A.7242BAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, We are running Postgres 8.2.5. I have 3 tables, call them A, B, and C 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. So my question is this: Shouldn't VACUUM FULL clean Table C and reclaim all its space? It doesn't. It usually reports the same number of pages before and after the Vacuum. We have to resort to TRUNCATE to clean and reclaim this table, which Must be empty at the beginning of function D. Any insights appreciated. Thanks, Mark Steben Senior Database Administrator @utoRevenueT A Dominion Enterprises Company 480 Pleasant Street Suite B200 Lee, MA 01238 413-243-4800 Home Office 413-243-4809 Corporate Fax msteben @autorevenue.com Visit our new website at www.autorevenue.com IMPORTANT: The information contained in this e-mail message is confidential and is intended only for the named addressee(s). If the reader of this e-mail message is not the intended recipient (or the individual responsible for the delivery of this e-mail message to the intended recipient), please be advised that any re-use, dissemination, distribution or copying of this e-mail message is prohibited. If you have received this e-mail message in error, please reply to the sender that you have received this e-mail message in error and then delete it. Thank you. ------=_NextPart_000_00F8_01C8891A.7242BAF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

We are running Postgres 8.2.5.

I have 3 tables, call them A, B, and = C

 

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.

 

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

It doesn’t.  It usually reports the same number of = pages before and after the Vacuum.

We have to resort to TRUNCATE to clean and reclaim this table, = which

Must be empty at the beginning of function D. =

 

Any insights appreciated. Thanks,

 

Mark Steben

Senior Database Administrator
@utoRevenue™
A Dominion = Enterprises Company
480 = Pleasant Street
Suite = B200
Lee, MA 01238
413-243-4800 Home Office 
413-243-4809 Corporate Fax

msteben@autorevenue.com

Visit our = new website at
www.autorevenue.com

 

IMPORTANT: The information = contained in this e-mail message is confidential and is intended only for the named addressee(s). If the reader of this e-mail message is not the intended recipient (or the individual responsible for the delivery of this e-mail message to the intended recipient), please be advised that any re-use, dissemination, distribution or copying of this e-mail message is = prohibited.  If you have received this e-mail message in error, please reply to = the sender that you have received this e-mail message in error and then = delete it.  Thank you.

 

------=_NextPart_000_00F8_01C8891A.7242BAF0--