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 1suPUA-006VT3-TW for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 04:55:15 +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 1suPU9-002d2U-9M for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 04:55:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1suPU8-002d2M-TN for pgsql-general@lists.postgresql.org; Sat, 28 Sep 2024 04:55:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1suPU4-001Spf-LN for pgsql-general@postgresql.org; Sat, 28 Sep 2024 04:55:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 48S4t6xC771901; Sat, 28 Sep 2024 00:55:06 -0400 From: Tom Lane To: Ron Johnson cc: pgsql-general Subject: Re: Regarding use of single column as primary key on partitioned table In-reply-to: References: Comments: In-reply-to Ron Johnson message dated "Sat, 28 Sep 2024 00:49:35 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <771899.1727499306.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sat, 28 Sep 2024 00:55:06 -0400 Message-ID: <771900.1727499306@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ron Johnson writes: > On Sat, Sep 28, 2024 at 12:39 AM David G. Johnston < > david.g.johnston@gmail.com> wrote: >> On Friday, September 27, 2024, Durgamahesh Manne < >>> 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. You can call it a flaw if you want, but it's an intentional design limitation. The only way to relax it would be to invent global indexes (that is, single indexes covering the entire partitioning tree), which would basically throw away every advantage of making a partitioned structure in the first place. If that's what you want, don't partition your table. regards, tom lane