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 1m2jyH-0007fo-4N for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 00:38:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m2jyG-0003Af-3k for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 00:38:52 +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 1m2jyF-0003AX-Oa for pgsql-performance@lists.postgresql.org; Mon, 12 Jul 2021 00:38:51 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m2jyD-0001xF-4A for pgsql-performance@postgresql.org; Mon, 12 Jul 2021 00:38:50 +0000 Received: by mail-io1-xd34.google.com with SMTP id g22so20441648iom.1 for ; Sun, 11 Jul 2021 17:38:48 -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=xFhUZyE3fiNv+DUmHh2Ol5aA3v8QkpBclcTFV1f5QkI=; b=ySgzI14G3l69XiIqkyTu2Zu196mI/q66zsafPmrNBvpc0AgjGPTQ5R878gPEJQM1Qs FRUppH9LLmWCSJqFfvfYmDLymD3JMCaZatGY1TZIxzJqS7kBeFySe+WEDmqYdPdajbJ5 lTriavAd8D0eCMuS4REzDnu3ghTaJ5upG3cT6RYUut5Y8FMt2g03u4CTZPa6DltxONlm EqTe7aRl8aLXrHiCZZwWJVrXMKeyV8SdZkAkMFS5/lt/i7O9Eb2pHs5E5t9P5PAISMVX ZwU9qTvW1Z0+WY6pZWUXjJT0piZbnqXDxcVEKruY7zX+1LrSjIv3U694L9LdUP7Rtx/3 yzLA== 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=xFhUZyE3fiNv+DUmHh2Ol5aA3v8QkpBclcTFV1f5QkI=; b=GLYtN+JmRX4f8vxxw6V6kwsmcsBNggkptaQ1djzWice4LSRHzpDzXupER4NG7g7QHF Slp1mMWGeqPehrpOgdZz8mzsoKKIAP6t65m9NoRrjJVXMQyOGSjc4baIy90JERdKOHYN d2pvY8NTS8v0qXKktzDQwSivB02ET8Bjlc6VpOOV2mu6l4C1j3f1gDNX3KFwnMUYJJBA sTrxaHg1Psm8tQcjzzhHhi7v3/giFJwL3SUVsxKAzOoirLZQoSZmqajmFV4Mi98aK6HO Pnc0f7lLthgTXmiwCwxD4V29BOI6dW+iapbU8Scn/GCch0xb33+fgK6rGyJUc4A5xRid iiBw== X-Gm-Message-State: AOAM533Wilcp2dohNIPMU1ujLZjieVhWmQ++8rB90gLHllgua5bZ0c87 mrb9KP92G0FixawHn4TjC7eihw== X-Google-Smtp-Source: ABdhPJyGHbTFsYjn5UQ1cERkZUNo9EaOu1BCBm3auHbN5ugKRaDQlRwDTpbmJuZFGNSo6sbH4zySBA== X-Received: by 2002:a6b:5b01:: with SMTP id v1mr34729100ioh.132.1626050328197; Sun, 11 Jul 2021 17:38:48 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id u15sm1651793ion.34.2021.07.11.17.38.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jul 2021 17:38:47 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id D336F800C52; Sun, 11 Jul 2021 19:38:46 -0500 (CDT) Date: Sun, 11 Jul 2021 19:38:46 -0500 From: Justin Pryzby To: Nagaraj Raj Cc: Mike Sofen , Alvaro Herrera , pgsql-performance@postgresql.org Subject: Re: Partition column should be part of PK Message-ID: <20210712003846.GA2004@telsasoft.com> References: <20210708221703.GA1301@telsasoft.com> <202107082228.obnak7c7mx4n@alvherre.pgsql> <080901d7744e$ac0f3d70$042db850$@runbox.com> <613808845.2913413.1625801566230@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <613808845.2913413.1625801566230@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 On Fri, Jul 09, 2021 at 03:32:46AM +0000, Nagaraj Raj wrote: > My apologies for making confusion with new thread. Yes its same issue related to earlier post. > I was trying to figure out  how to ensure unique values for columns (billing_account_guid, ban). If i add partition key to constraint , it wont be possible what im looking for. > My use case as below  > INSERT INTO t1 SELECT * from t2 ON CONFLICT (billing_account_guid,ban) DO UPDATE SET something… > > Or > INSERT INTO t1 SELECT * from t2 ON CONFLICT constraint (pk or uk)(billing_account_guid,ban) DO UPDATE SET something… I'm not sure, but did you see the 2nd half of what I wrote in June ? lightly edited: > It sounds like you want a unique index on (billing_account_guid, ban) to > support INSERT ON CONFLICT. If DO UPDATE SET will never move tuples to a new > partition, then you could do INSERT ON CONFLICT to a partition rather > than its parent. > > But it cannot be a unique, "partitioned" index, without including load_dttm. You could try something that doesn't use a parent/partitioned index (as I was suggesting). Otherwise I think you'd have to partition by something else involving the unique columns, or not use declarative partitioning, or not use insert on conflict. Justin PS, I'm sorry for my own confusion, but happy if people found it amusing.