Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozPdE-00023b-3p for pgsql-admin@arkaria.postgresql.org; Sun, 27 Nov 2022 21:56:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozPdD-00042L-1P for pgsql-admin@arkaria.postgresql.org; Sun, 27 Nov 2022 21:56:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozPdC-0003wm-ID for pgsql-admin@lists.postgresql.org; Sun, 27 Nov 2022 21:56:10 +0000 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozPd7-0007sy-EC for pgsql-admin@lists.postgresql.org; Sun, 27 Nov 2022 21:56:09 +0000 Received: by mail-qt1-x835.google.com with SMTP id h24so5612661qta.9 for ; Sun, 27 Nov 2022 13:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=LnN9WRVSv/yhhQ+Qm4SwHCy/NfbkguSkLan/Wnxjnss=; b=Yj6iZ+Ue25UxlMDbpEP7/CLNhM7s/rlzmooeHjJNmDdc3O7rAF9zsojz7NDxvw2QZU 9SYfoW24Lx6ZhHxww4O2YIY03qDSzOgxpniqZmztDMI095DLBryXLBnWLmadPuSIQF+7 WFO6x0x3OrVG+Htttd9Mops8QTJiP/Owij1KDbyfr9d1kKPa7TT0wJD3X4JRwT++zsWi FmwQx+ugX/UFZLs7JjCTWJb6QaE2H/jQBjVJQKHuxy03lb+bExlDhlQemEknFXl57BJd csYcQ1dMA9tHmiHiQxAX269fFfFbMqKdgCFmApE2rkP57TzlpbtogBHxMcmIr5/Bg7Ky RDvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=LnN9WRVSv/yhhQ+Qm4SwHCy/NfbkguSkLan/Wnxjnss=; b=av9wmVyNrfB82GCzXqFA7mLmzqQGHDxFxLYFj385OaphpxYlcXrIJ1nytjXgD3/jll v+MKaWTYX7GL0QWPg9hp65JjFB5Bc3uAyeoIYzz3mHopztzc5PMzGa+dY1d5kC14bIgj Mq2VSe5eSNviPwH2GoMSu318Jh/52HJfyJqUZgpLqJ10yT37d6GkbY7ZEMyLZTgcx29X MIH1y0kkpX2MvDqNRvaAhVVgEpTSsE9zzGguWHr+XHG8YzAi/8my70A9Fapv6j4XRH9d ffOCTkxWSZSbAnn5hvY2FszAqRkNXQNHlrpiB+CsPxJtkhRnSRN1SLy3FT9Vd2HKrRvr RP8A== X-Gm-Message-State: ANoB5pkLsTNw8zsKP2h0OO/6ARDWjnh2pBIJ/BR/LVJRCeiKiz4rKjRp DBS7PLihEWbTYA2RiLGKOWOzx+W9kOLpVA== X-Google-Smtp-Source: AA0mqf6pqjtlYqhPrSe8GCbd3Hh6chhC17pH4M4kfch0IDh/gvH3CT4pptka/O2sRyJ9oXh4iXnxhw== X-Received: by 2002:ac8:5194:0:b0:3a5:2bd0:67ab with SMTP id c20-20020ac85194000000b003a52bd067abmr44499193qtn.289.1669586164292; Sun, 27 Nov 2022 13:56:04 -0800 (PST) Received: from [192.168.2.100] (pool-72-79-30-4.nwrknj.east.verizon.net. [72.79.30.4]) by smtp.gmail.com with ESMTPSA id h11-20020ac8714b000000b00342f8d4d0basm5888734qtp.43.2022.11.27.13.56.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 13:56:03 -0800 (PST) Content-Type: multipart/alternative; boundary="------------5cLMSAWtD9OmDcSoMjFac0Ic" Message-ID: <88df5cb3-913f-182e-22ed-cbdc62fdd7d6@gmail.com> Date: Sun, 27 Nov 2022 16:56:03 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Disable unique constraint in Postgres To: pgsql-admin@lists.postgresql.org References: Content-Language: en-US From: Mladen Gogala In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------5cLMSAWtD9OmDcSoMjFac0Ic Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/27/22 16:23, Ron wrote: > > Being an "enterprise dba", IMNSHO "disable constraint" (and more > specifically "*disable index*") is a /great/ feature for maintaining > tables.  For example, if you need to purge a *lot* of records into a > table, disable all indices except the index supporting your WHERE > CLAUSE, delete the data, and then re-enable the indices.  Bonus points > if the REENABLE commands can be done in parallel. > > Sure, you /can/ dig around for all of the CREATE INDEX statements, but > that leads to possible errors: "oops, forgot to recreate one of them", > or "typo caused one to fail".  OTOH, DISABLE INDEX and REENABLE INDEX > are idiot-proof, and can be automated. > > -- > Angular momentum makes the world go 'round. You are aware that in Oracle "ALTER TABLE ENABLE CONSTRAINT" rebuilds the index used to enforce the constraint? You will not save any time by disabling and re-enabling constraints. -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com --------------5cLMSAWtD9OmDcSoMjFac0Ic Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 11/27/22 16:23, Ron wrote:

Being an "enterprise dba", IMNSHO "disable constraint" (and more specifically "disable index") is a great feature for maintaining tables.  For example, if you need to purge a lot of records into a table, disable all indices except the index supporting your WHERE CLAUSE, delete the data, and then re-enable the indices.  Bonus points if the REENABLE commands can be done in parallel.

Sure, you can dig around for all of the CREATE INDEX statements, but that leads to possible errors: "oops, forgot to recreate one of them", or "typo caused one to fail".  OTOH, DISABLE INDEX and REENABLE INDEX are idiot-proof, and can be automated.

--
Angular momentum makes the world go 'round.


You are aware that in Oracle "ALTER TABLE ENABLE CONSTRAINT" rebuilds the index used to enforce the constraint? You will not save any time by disabling and re-enabling constraints.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--------------5cLMSAWtD9OmDcSoMjFac0Ic--