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 1m1cKX-0003Cw-O1 for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jul 2021 22:17:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1cKV-0007qz-3E for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jul 2021 22:17:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1cKU-0007qr-Oo for pgsql-performance@lists.postgresql.org; Thu, 08 Jul 2021 22:17:10 +0000 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m1cKR-0002XF-Kt for pgsql-performance@postgresql.org; Thu, 08 Jul 2021 22:17:10 +0000 Received: by mail-il1-x12b.google.com with SMTP id i13so8193908ilu.4 for ; Thu, 08 Jul 2021 15:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=zDkSIW3eSYVK7mH07alCnB72eGw7516MvYjsmhCKcNE=; b=hzAG9MnFBNjKOg3ldI2989AC9vxiCV1PugsFsq0V/wWh/nPHEf3d5wOvaVtWrmYu+X J6e6KeiS6Jexbmcuml0UW7l9sPjF2Yjv93U3QX+BXDqKwEghjnBC2NGQBubzErcgAIQn B1tnlFepC5V5E6E9IqrYJFBRQMQzoGZaT0iA8XS+MeUs1xH4FJNle2UFNEHoYjuQy8vO JAhZTElZDBfwIElzpI6PAsLoJX9+dQLcSHBQjtYOhvHQLmkmKk88yY/WFNEujojjnP1W qOO0TbewZQ3+FihYL0a/8KtdDZhY+ki7CWHEVIgavJHnW9K8GyYakAwhrkrKzHnRKXbA o84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=zDkSIW3eSYVK7mH07alCnB72eGw7516MvYjsmhCKcNE=; b=RHhwdKUHVmYC5cotgpJYOT1T7gfd9sonfjGax/Um09rGezbXI3AdE44hGOrSf7l5jO 7gsy+ZRT5zVweCTjO4RgMlMRHUaAkWj7EhGsgll5fPl01Rk0+VPYkbydapLl/g0CREzu I5qb9ml+AuKxXFdZC63eKlvJjgrImXXsCQu6gcK1UNL/VhMrTFNxyVEZNIn488knC6Or nWQLp9pepc498FiDiK5UU2fhsN0RTTWjrWzzWClk4kuYU6zBahe0QtvWOMPQClKd1s8w AFZFrMwVj1sMMk4CWtTnqaR68txw9qJKEKOefMCnGqh9ph0HTy4LUvQG3tzbtUYWZZhT RS5Q== X-Gm-Message-State: AOAM530FhpKn1uOve1J8c2L1piw0AI/mAqiEkTG/B8h2OaMh4aY3iko1 6By79ipbUsqfMJ1q6xDr4CyHRQvWIDD29w== X-Google-Smtp-Source: ABdhPJz6aqGg7UPPx5Nu+8ce32XOHG1/Wwhk3M9FgWuIT7frvx/0PbYoSrQBx+IUeQ3XID6bgAclLQ== X-Received: by 2002:a92:c503:: with SMTP id r3mr9961617ilg.148.1625782625045; Thu, 08 Jul 2021 15:17:05 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t11sm1921634iob.5.2021.07.08.15.17.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jul 2021 15:17:04 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 81F01800B3E; Thu, 8 Jul 2021 17:17:03 -0500 (CDT) Date: Thu, 8 Jul 2021 17:17:03 -0500 From: Justin Pryzby To: Nagaraj Raj Cc: pgsql-performance@postgresql.org Subject: Re: Partition column should be part of PK Message-ID: <20210708221703.GA1301@telsasoft.com> References: <836265572.4593017.1624590607279.ref@mail.yahoo.com> <836265572.4593017.1624590607279@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <836265572.4593017.1624590607279@mail.yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk If I'm not wrong, this is the same thing you asked 2 week ago. If so, why not continue the conversation on the same thread, and why not reference the old thread ? I went to the effort to find the old conversation. https://www.postgresql.org/message-id/20210625042228.GJ29179@telsasoft.com If declaratively partitioned tables and partitioned indexes don't do what you wanted, then you should consider not using them for this. On Fri, Jun 25, 2021 at 03:10:07AM +0000, Nagaraj Raj wrote: > we have some partitioned tables with inherence and planning to migrate them to the declaration. > Table DDL: > CREATE TABLE c_account_p > ( >     billing_account_guid character varying(40)  NOT NULL, >     ingestion_process_id bigint NOT NULL DEFAULT '-1'::integer, >     load_dttm timestamp(6) without time zone NOT NULL, >     ban integer NOT NULL, >     CONSTRAINT billing_account_pkey PRIMARY KEY (billing_account_guid, ban) > ) PARTITION by RANGE(load_dttm); > When I try the create table, it's throwing below error: > ERROR:  insufficient columns in the PRIMARY KEY constraint definition > DETAIL:  PRIMARY KEY constraint on table "l_billing_account_p" lacks column "load_dttm" which is part of the partition key. > SQL state: 0A000 > Is it mandatory/necessary that the partition column should be a primary key? cause if I include load_dttm as PK then it's working fine.db<>fiddle > If the partition column should be supposed to be a PK, it's challenging to create a partition by range with the date column, cause the load_dttm column chances to have duplicate if data loaded COPY or INSERT.INSERT INTO c_account_p SELECT * from c_account_p_bkp ON CONFLICT (billing_account_guid,ban,load_dttm) DO UPDATE SET 'some stuff..' > If I receive billing_account_guid, ban combination with different load_dttm then it will end up with duplicate keys. > Could some please help me to understand this scenario? > Thanks.