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 030EA52951 for ; Fri, 10 Jun 2005 06:05:56 -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 55022-03 for ; Fri, 10 Jun 2005 09:05:46 +0000 (GMT) Received: from mx.mall.cz (mx.mall.cz [62.168.45.106]) by svr1.postgresql.org (Postfix) with ESMTP id 0E3D452862 for ; Fri, 10 Jun 2005 06:05:44 -0300 (ADT) Received: from localhost (asterix [127.0.0.1]) by mx.mall.cz (Postfix) with ESMTP id 29B7413F607 for ; Fri, 10 Jun 2005 11:05:44 +0200 (CEST) Received: from mx.mall.cz ([127.0.0.1]) by localhost (asterix [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 05373-02 for ; Fri, 10 Jun 2005 11:05:43 +0200 (CEST) Message-ID: <42A957E9.8040909@mall.cz> Date: Fri, 10 Jun 2005 11:05:45 +0200 From: Michal Taborsky User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Cleaning bloated pg_attribute Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at mall.cz X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200506/234 X-Sequence-Number: 12871 I managed, by extensive usage of temporary tables, to totally bloat pg_attribute. It currently has about 40000 pages with just 3000 tuples. The question is, how to restore it to it's former beauty? With ordinary table I'd just CLUSTER it, but alas! I cannot do that with system catalog. I always get: db=# cluster pg_attribute_relid_attnam_index on pg_attribute; ERROR: "pg_attribute" is a system catalog The only thing I could think of is VACUUM FULL, but from my former experience I guess it'll take maybe over an hour, effectively rendering the server unusable, because of the exclusive lock. It is a live 24/7 system, so I'd really prefer something less drastic than dumping and reloading the database (though it's still shorter downtime than with the vacuum.) Isn't there a way to somehow go around the above mentioned limitation and CLUSTER the table? Thanks for your ideas. -- Michal Táborský CTO, Internet Mall, a.s. Internet Mall - obchody, které si oblíbíte