X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 604B85280B for ; Thu, 16 Jun 2005 15:04:52 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 07633-10 for ; Thu, 16 Jun 2005 18:04:43 +0000 (GMT) Received: from web33703.mail.mud.yahoo.com (web33703.mail.mud.yahoo.com [68.142.201.200]) by svr1.postgresql.org (Postfix) with SMTP id C9BA852824 for ; Thu, 16 Jun 2005 15:04:42 -0300 (ADT) Received: (qmail 8985 invoked by uid 60001); 16 Jun 2005 18:04:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ah1x3PohhLJQHVxVXriubJvmOi1uYb5fWefN6mq7T3XMbXxucmy2/zzuqC5i6Miksfg8+0AQB1ritTsopC/kUPxmwr1v7rmTq1swm5gV2xCMeXMY6Hv7U+Q96wBpUS4x1Zpo9vUEHf+hHTKsp7Phdi9KXe10afL9rlARWDxrPCc= ; Message-ID: <20050616180442.8983.qmail@web33703.mail.mud.yahoo.com> Received: from [68.40.151.218] by web33703.mail.mud.yahoo.com via HTTP; Thu, 16 Jun 2005 11:04:41 PDT Date: Thu, 16 Jun 2005 11:04:41 -0700 (PDT) From: ken shaw Subject: How to determine whether to VACUUM or CLUSTER To: pgsql-performance@postgresql.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1679030748-1118945081=:7587" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=4.736 tagged_above=0 required=5 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE X-Spam-Level: **** X-Archive-Number: 200506/338 X-Sequence-Number: 12975 --0-1679030748-1118945081=:7587 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi All, I have an app that updates a PostgreSQL db in a batch fashion. After each batch (or several batches), it issues VACUUM and ANALYZE calls on the updated tables. Now I want to cluster some tables for better performance. I understand that doing a VACUUM and a CLUSTER on a table is wasteful as the CLUSTER makes the VACUUM superfluous. The app does not have a built-in list of the tables and whether each is clustered or not. It looks to me as if the only way to determine whether to issue a VACUUM (on a non-clustered table) or a CLUSTER (on a clustered table) is to query the table "pg_index", much like view "pg_indexes" does, for the column "indisclustered". Is this right? Also, how expensive is CLUSTER compared to VACUUM? Does CLUSTER read in the whole table, sort it, and write it back out? Or write out a completely new file? Is the time for a CLUSTER the same whether one row is out of place or the table is completely disordered? Thanks, Ken --------------------------------- Discover Yahoo! Find restaurants, movies, travel & more fun for the weekend. Check it out! --0-1679030748-1118945081=:7587 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi All,

I have an app that updates a PostgreSQL db in a batch fashion. After each batch (or several batches), it issues VACUUM and ANALYZE calls on the updated tables. Now I want to cluster some tables for better performance. I understand that doing a VACUUM and a CLUSTER on a table is wasteful as the CLUSTER makes the VACUUM superfluous. The app does not have a built-in list of the tables and whether each is clustered or not. It looks to me as if the only way to determine whether to issue a VACUUM (on a non-clustered table) or a CLUSTER (on a clustered table) is to query the table "pg_index", much like view "pg_indexes" does, for the column "indisclustered". Is this right?

Also, how expensive is CLUSTER compared to VACUUM? Does CLUSTER read in the whole table, sort it, and write it back out? Or write out a completely new file? Is the time for a CLUSTER the same whether one row is out of place or the table is completely disordered?

Thanks,

Ken


Discover Yahoo!
Find restaurants, movies, travel & more fun for the weekend. Check it out! --0-1679030748-1118945081=:7587--