Re: Recreate primary key without dropping foreign keys?
От | Frank Lanitz |
---|---|
Тема | Re: Recreate primary key without dropping foreign keys? |
Дата | |
Msg-id | 4F8BDAB2.7010209@frank.uvena.de обсуждение исходный текст |
Ответ на | Re: Recreate primary key without dropping foreign keys? (Chris Ernst <cernst@zvelo.com>) |
Ответы |
Re: Recreate primary key without dropping foreign keys?
|
Список | pgsql-admin |
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 <cernst@zvelo.com> >> 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
В списке pgsql-admin по дате отправления: