Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1suPOx-006Urd-6O for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 04:49:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1suPOw-002X4P-7y for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 04:49:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1suPOv-002X49-Sc for pgsql-general@lists.postgresql.org; Sat, 28 Sep 2024 04:49:49 +0000 Received: from mail-oo1-xc2b.google.com ([2607:f8b0:4864:20::c2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1suPOt-001QTA-HD for pgsql-general@postgresql.org; Sat, 28 Sep 2024 04:49:48 +0000 Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5d5f24d9df8so1367023eaf.2 for ; Fri, 27 Sep 2024 21:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727498986; x=1728103786; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=MFtKktB5/fnpsMNs5D0GC/3NqpGBUSFI6fUa85lD53g=; b=AtcIg/vrU9LB5qTBIhyRq6kavCIxmWABH+vfSyLDlsBS6KARuFR12bNzBpeKr44F2K WXyF0jnjt9r2eXImbLtuiji+/mNC3fEKkPJ/9O+eAkbNuGwfPqGWnc5MmEIB4dIARHu5 iy5nFo3zcedGUVUwKDRzkfJvBfJo1Ji4tnc628V3Uik0l8rw+td2EatSiHpWOUI9AP7A jlbIyGHbkPQFzjFindlL3PnNrLoVQj35Boswf431SFukG/vBagCyjJ+nGu9hCZpU87J+ kDv+BmvLYwTQaxsbXd4+6inXJgDvbbfdTXibN3BJFztMWZus119NYDLT8eGybiNYwB+Y 2M6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727498986; x=1728103786; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MFtKktB5/fnpsMNs5D0GC/3NqpGBUSFI6fUa85lD53g=; b=U9Hn7ujFJkJ6oV4rM9OcszrDSzAcf+C+Q0C36PWXcB+XSs1aSDN8BJAxfkhDW7C8fc 2Kxhoe7JVeWcP6tIn8x2DMiy+OXMn7xz+Jhj5O6UaWvO305x93BOMULVVKr/DAn5bGZs R/FNcWC6T9qUtHDzpanEjbnsokQ0PsxM0HEvxYIyLuW1P5m8GL5XlKvTEceifevVD/W2 JOpkjOVq2mA+8X/yJ0o9XsSAw1RlEiyyi9H3CrnWaIHSpbOV6te/8vj1wgsSWSLk0oHn cIkH22bZNd811zUWsFz1MYLTT5jgFbWndxdsq/mhINXiIWav4sgnk0Zta97rq/GDAkD9 aqhg== X-Gm-Message-State: AOJu0YyjUixk/HEvYxWUYwWbMaQ96gB4sO+Xqj4CizObA3ai89MIFMm+ y3btZG0KMMNzx8FYUuXDRb9EIj5diqtqTBizybzzaCThMBVi7w9Ot2GTNPcb8P4vwPE7qJQ5KzK d4VoFUIYhsErPeSYGpJEBLABeoilZSQ== X-Google-Smtp-Source: AGHT+IG7BqUscjXbEdCjNqDGAbRoxdiCRAflesaBwCY6YPGtkipuxn6GhT4P6SKEJKchXQRom4e4p3JuzVEF/G5duFY= X-Received: by 2002:a05:6870:6c09:b0:270:64ed:c125 with SMTP id 586e51a60fabf-28710a5e48bmr3584806fac.16.1727498986623; Fri, 27 Sep 2024 21:49:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Sat, 28 Sep 2024 00:49:35 -0400 Message-ID: Subject: Re: Regarding use of single column as primary key on partitioned table To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000729a11062326b3e3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000729a11062326b3e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 28, 2024 at 12:39=E2=80=AFAM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Friday, September 27, 2024, Durgamahesh Manne < > maheshpostgres9@gmail.com> wrote: > >> >> ERROR: unique constraint on partitioned table must include all >> partitioning columns >> DETAIL: PRIMARY KEY constraint on table "bet" lacks column "placedon" >> which is part of the partition key. >> test=3D> >> >> Can't we use primary key on singal column(betid) on partitioned table >> rather than using composite key (placedon,betid)? >> > > No. It would be misleading to allow such a thing because a unique index > can only span a single partition. > That is IMO a serious (and probably unfixable, given how PG stores tables) flaw in PG's partitioning design. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. crustacean! --000000000000729a11062326b3e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 28, 2024 at 12:39=E2=80=AFAM = David G. Johnston <david.g= .johnston@gmail.com> wrote:
On Friday, September 27, 2024= , Durgamahesh Manne <maheshpostgres9@gmail.com> wrote:

ERROR: =C2=A0uni= que constraint on partitioned table must include all partitioning columnsDETAIL: =C2=A0PRIMARY KEY constraint on table "bet" lacks colum= n "placedon" which is part of the partition key.
test=3D>

Can't we use primary key on singal column(b= etid) on partitioned table rather than using composite key (placedon,betid)= ?

No.=C2=A0 It would be mislead= ing to allow such a thing because a unique index can only span a single par= tition.

That is IMO = a serious (and probably unfixable, given how PG stores tables) flaw in PG&#= 39;s partitioning design.

--
Death to <Redacted>, and butter sauce.
Don't boil me= , I'm still alive.
<Redacted> crustacean!
--000000000000729a11062326b3e3--