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 1l4PDc-0002Kk-1W for pgsql-admin@arkaria.postgresql.org; Tue, 26 Jan 2021 14:21:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l4PDa-0002OW-Ma for pgsql-admin@arkaria.postgresql.org; Tue, 26 Jan 2021 14:21:18 +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 1l4PDa-0002OP-DI for pgsql-admin@lists.postgresql.org; Tue, 26 Jan 2021 14:21:18 +0000 Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l4PDU-0006Pl-3R for pgsql-admin@lists.postgresql.org; Tue, 26 Jan 2021 14:21:17 +0000 Received: by mail-ot1-x330.google.com with SMTP id i30so16301575ota.6 for ; Tue, 26 Jan 2021 06:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=w8/pdg7mPBnEUZ4evPfsENsBZ7vHRlFTCQR6SWVUBa4=; b=peMyLTurBOlXMWnZ0jb1hOE2pp7TwY/FXMWmT7IIWjbR9F8UBNxRArmoLaeNkYGfJF RNzwhAtu0ctgsa6Yo3tQKFcKwyiyvfkFS+AA2tUUe5Ra8qc9nZQGr9VZdcK8dJeFtSFH L0hsekYcLRjLK/9MqwPSXQSIZGQDG1cvcuSj1lJ/EJxfdtXLVsJbH9BreUqB53pQ3uQI c3+MGV+efgNBlZnZSjU0aHHosy2Lk7hdgqijcaCUX092xKr5GjCJoHfSuGvCwzrZon+i GNF7gU0ujsT6wh/1sv7FdaSCuDqLkkWgJOdvNxUFqwNnW5WnEXRSYjUzrJX0WE6mwF+J U2Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=w8/pdg7mPBnEUZ4evPfsENsBZ7vHRlFTCQR6SWVUBa4=; b=A0EtMVcvAiKJC1hDdo06r6foayCKbKEKaur9o9X47CA9qH2rg+VdSOmU4ELNrm7+Wj k/mh/BgY8gn2hYWkSUeIXv54MJ+VQtNswohtjfZbuDqfx9/RUhfzqdweFB+aN/ZxpPmm XJ9MYWGbIhzW+++cXY9a0KViN5nrJzN63gn0YIx8Sszul8q3hl/BhTjGaYdiW+KVyMMv yFdRtld7tveJxRfEC5yJCGE0N6Mn2hL599pCjbS8wZiC2eEvCpRrlIxY+0IJN0OJjKU+ +5xDrIGAgvOE2OW+ypegPZ2SqjH5TwTD8bL9ISzJqJLuJHpG+4HYlD/Iizw8qQx0FXzo uvZQ== X-Gm-Message-State: AOAM532RnbUHchuoQD3W/7Mq4QOF/Yx5YGVp7n0V/pSe2/92V1jeL62v zPFJfm2dBDGHacKTiioSkVob/QEgnmbnIw== X-Google-Smtp-Source: ABdhPJxBfdfIJ0zckxWurqXPlgdyE2ISDL0tsbHyqy+LitgQkacYFg+Z7VJzhdC2ZjQlJJyf8Y4Jqw== X-Received: by 2002:a9d:bac:: with SMTP id 41mr4096908oth.262.1611670871033; Tue, 26 Jan 2021 06:21:11 -0800 (PST) Received: from [192.168.88.10] (ip174-67-141-204.no.no.cox.net. [174.67.141.204]) by smtp.googlemail.com with ESMTPSA id c18sm2674093oov.20.2021.01.26.06.21.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Jan 2021 06:21:10 -0800 (PST) Subject: Re: Unique constraint across all partitions? To: Pgsql-admin References: <3d00c1f4-646c-59b7-e4dc-1d51190d2139@gmail.com> <5ebaba7ee42d89f8bfb2599de203612024c86e8e.camel@cybertec.at> From: Ron Message-ID: <8ae682ca-2761-7cd5-d844-7e40bf5a7989@gmail.com> Date: Tue, 26 Jan 2021 08:21:09 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5ebaba7ee42d89f8bfb2599de203612024c86e8e.camel@cybertec.at> Content-Type: multipart/alternative; boundary="------------0A675DDC96E4C233756C7196" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------0A675DDC96E4C233756C7196 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/26/21 2:33 AM, Laurenz Albe wrote: > On Mon, 2021-01-25 at 18:09 -0600, Ron wrote: >>>>> Is it possible to enforce a unique constraint across all partitions for >>>>> either declarative or inheritance based partitioning? Preferably >>>>> declarative based. >>> So, yes, so long as your unique constraint takes into consideration the partitioning scheme it will enforce uniqueness across all of the partitions. But the answer to the full, but possibly >>> implied, question is no. >> >> This is why global indices are needed. > Global indexes are likely more pain than gain. > > They will make the best part of partitioning (attaching and detaching > partitions) painfully slow. Hardly worth it to gain a tiny little bit > of integrity. Within a partition, you can guarantee uniqueness easily. Don't make my decisions for me. When a PK or FK without an embedded partition key are needed, you bite the bullet and take the 9 hour downtime.  (A legacy RDBMS I occasionally still maintain has had them for *25 years*. What's just as useful are indices partitioned on keys which have nothing to do with the table's partition key.) -- Angular momentum makes the world go 'round. --------------0A675DDC96E4C233756C7196 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 1/26/21 2:33 AM, Laurenz Albe wrote:
On Mon, 2021-01-25 at 18:09 -0600, Ron wrote:
Is it possible to enforce a unique constraint across all partitions for 
either declarative or inheritance based partitioning? Preferably 
declarative based.
So, yes, so long as your unique constraint takes into consideration the partitioning scheme it will enforce uniqueness across all of the partitions.  But the answer to the full, but possibly
implied, question is no.
 
This is why global indices are needed.
Global indexes are likely more pain than gain.

They will make the best part of partitioning (attaching and detaching
partitions) painfully slow.  Hardly worth it to gain a tiny little bit
of integrity.  Within a partition, you can guarantee uniqueness easily.

Don't make my decisions for me.

When a PK or FK without an embedded partition key are needed, you bite the bullet and take the 9 hour downtime.  (A legacy RDBMS I occasionally still maintain has had them for 25 years.  What's just as useful are indices partitioned on keys which have nothing to do with the table's partition key.)

--
Angular momentum makes the world go 'round.
--------------0A675DDC96E4C233756C7196--