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 1skUJg-000VPo-UA for pgsql-general@arkaria.postgresql.org; Sat, 31 Aug 2024 20:03:25 +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 1skUIh-002rJy-O0 for pgsql-general@arkaria.postgresql.org; Sat, 31 Aug 2024 20:02:23 +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 1skUIh-002rGD-Be for pgsql-general@lists.postgresql.org; Sat, 31 Aug 2024 20:02:23 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1skUIf-00023g-RA for pgsql-general@lists.postgresql.org; Sat, 31 Aug 2024 20:02:22 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2f5064816edso32481591fa.3 for ; Sat, 31 Aug 2024 13:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725134540; x=1725739340; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Skn48Aua2tfRUSftVx5maZskJw6bVxHN5tffc3tdm5o=; b=aVXXIuBYkPLW3uOQJ+TaWC3Qq4KBTfeg+ao7tpuP6WFZ26q6V2BlwtnhGo62nyHUP4 vnlMVl4Lc8nW8TsdKoCHcA0sPdldD42/inA90CS9Xv0daiEYzjyyyBREoc6LH1lKERbj CeUHwzEEX9kR5VIvOHV5MdBZBO2yhoptc6Wlm4NUSaTEeJWjKpvtxuejjSIJsp7GAYIH Gc23DqZb03cIqubCFHqHDrHRldgyMyoQfJAXRN+L4bG1fEuS9iE93XOs8ItwFyIUlp+9 B9i1hi8Qpc/FYdHed/I/9/3eZ+p/9ULW+il+Gx7+gMSK/4hxxHJiF3l6zOekR7r69nWq oLMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725134540; x=1725739340; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Skn48Aua2tfRUSftVx5maZskJw6bVxHN5tffc3tdm5o=; b=E+NopSXhioZcEltG80+whSGFQW3dDlrSoMH3u3YuJ1H6RPaEp/SOLkIZ9xBH+wii8o XQBdwCJvFZCfuwW/sq4U1sTwH1e0GWZxv3OzYesjelJ+ROSsrTp6rkyPRdp3thB5VMFP JcdK+Y48DCGH2Pb5nU7Yzs3G1POEHfkVrqD6RPArda7HxYuSH1JqC6am0mGn/MbUnJ35 27lzcPIPdV8TxVanlLSE6JNteRqQv5JR6G70G6MbE4cQl5cGMLb+FMl1SQu86cVpqFAf 1P1JkO4q4jw1AKy7T/TZhQ2L9KsMnheW0ybDc/jjXorpriqXVh10+BHPM5m5v9QTTZFK L7aw== X-Gm-Message-State: AOJu0Yw8NmEVWd2sUrZvTcrJXmv7lia1XWr279P3UopAuoUNu4QxpiPn djPmPN82r8L7E7R8BEtYIo6FxDeqocLq+2F+Pp3qr/2EEOv8IpYE31GNvLPR4Acka/wceAC/gh4 QTcdd+HwUCBALxZ+wQ6lQEiVTK3DUyQ== X-Google-Smtp-Source: AGHT+IGTTluxbqE9QmuPvDwejVWxZES4wn9vrKlIAsoT+jL0wESXNXOaJi/bT30k9TrRYVTO/UrI5Alxs7t6T+lnUjs= X-Received: by 2002:ac2:4e0d:0:b0:52f:d69e:bb38 with SMTP id 2adb3069b0e04-53546afd7c6mr4013622e87.2.1725134539654; Sat, 31 Aug 2024 13:02:19 -0700 (PDT) MIME-Version: 1.0 From: veem v Date: Sun, 1 Sep 2024 01:32:07 +0530 Message-ID: Subject: Partitioning and unique key To: pgsql-general Content-Type: multipart/alternative; boundary="0000000000006d11b10621002f1a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006d11b10621002f1a Content-Type: text/plain; charset="UTF-8" Hello, We have our transaction tables daily range partitioned based on transaction_timestamp column which is timestamptz data type and these are having composite primary key on (transaction_id, transaction_timestamp). And we were using an "insert on conflict" for loading data to our system , which means if another record comes to the system with the same transaction_id and transaction_timestamp, it will get updated. This way we already have 60 days worth of data stored in our system with approx. 70 million transactions per day. But we just got to know from business that the data should be unique by only transaction_id but not transaction_timestamp. Any incoming data with the same transaction_id(even different transaction_timestamp) should get updated but not inserted. Also these daily partitions are going to hold 400million rows in future and will be queried on the transaction_timestamp filter so we can't really avoid the partitioning option here considering future growth. But due to postgres limitations we are unable to have this unique constraint or primary key only on the transaction_id column, we have to include transaction_timestamp with it as a composite key. So I want to understand from experts if there is any possible way to satisfy both partitioning on transaction_timestamp column and unique key or pk just on *trans*action_id only? Note-its 15.4 postgres database. Regards Veem --0000000000006d11b10621002f1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,=C2=A0=

We have our = transaction tables daily range partitioned based on transaction_timestamp c= olumn which is timestamptz data type and these are having composite primary= key on (transaction_id, transaction_timestamp). And we were using an "= ;insert on conflict" for loading data to our system , which means if a= nother record comes to the system with the same transaction_id and transact= ion_timestamp, it will get updated. This way we already have 60 days worth = of data stored in our system with approx. 70 million transactions per day. =

= But we just got to know from business that the data should be unique by only transaction_id but not transa= ction_timestamp. Any incoming data with the same transaction_id(even differ= ent transaction_timestamp) should get updated but not inserted.

<= p dir=3D"ltr">Also these daily partitions are going to hold 400million rows= in future and will be queried on the transaction_timestamp filter so we ca= n't really avoid the partitioning option here considering future growth= .

But due to postgres limitation= s we are unable to have this unique constraint or primary key only on the t= ransaction_id column, we have to include transaction_timestamp with it as a= composite key. So I want to understand from experts if there is any possib= le way to satisfy both partitioning on transaction_timestamp column and uni= que key or pk just on trans<= /u>action_id only?=C2=A0

Note-its 15.4 postgres database.=C2=A0


Regards

Veem

--0000000000006d11b10621002f1a--