Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 71FF862698A for ; Mon, 16 Apr 2012 05:39:28 -0300 (ADT) Received: from uvena.de ([79.140.41.123]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SJhT3-0005DQ-4L for pgsql-admin@postgresql.org; Mon, 16 Apr 2012 08:39:26 +0000 Received: from [141.35.39.175] (c319808.zuv.uni-jena.de [141.35.39.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by uvena.de (Postfix) with ESMTPSA id E7921254088 for ; Mon, 16 Apr 2012 08:39:11 +0000 (UTC) Message-ID: <4F8BDAB2.7010209@frank.uvena.de> Date: Mon, 16 Apr 2012 10:39:14 +0200 From: Frank Lanitz User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Re: Recreate primary key without dropping foreign keys? References: <4F8B6AA1.1040709@zvelo.com> <20120416065717.70a31a6361ac5d7bdad416e8@frank.uvena.de> <4F8BD91C.6070405@zvelo.com> In-Reply-To: <4F8BD91C.6070405@zvelo.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201204/80 X-Sequence-Number: 39416 Am 16.04.2012 10:32, schrieb Chris Ernst: > On 04/15/2012 10:57 PM, Frank Lanitz wrote: >> On Sun, 15 Apr 2012 18:41:05 -0600 Chris Ernst >> wrote: >> >>> Hi all, >>> >>> In PostgreSQL 9.1.3, I have a few fairly large tables with >>> bloated primary key indexes. I'm trying to replace them using >>> newly created unique indexes as outlined in the docs. Something >>> like: >>> >>> CREATE UNIQUE INDEX CONCURRENTLY dist_id_temp_idx ON >>> distributors (dist_id); ALTER TABLE distributors DROP CONSTRAINT >>> distributors_pkey, ADD CONSTRAINT distributors_pkey PRIMARY KEY >>> USING INDEX dist_id_temp_idx; >>> >>> However, the initial drop of the primary key constraint fails >>> because there are a whole bunch of foreign keys depending on it. >>> >>> I've done some searching and haven't found a workable solution. >>> Is there any way to swap in the new index for the primary key >>> constraint without dropping all dependent foreign keys? Or am I >>> pretty much stuck with dropping and recreating all of the foreign >>> keys? >> >> REINDEX is not working here? > > Hi Frank, > > Thanks, but REINDEX is not an option as it would take an exclusive > lock on the table for several hours. Well, from my little view I guess all rebuilding index action would require such, as its the primary key with uniqueness. I'd think of a complete reinit of the cluster with pg_dump and restoring, but this would also need a downtime at least for write access. Why is the index so bloated? Cheers, Frank