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 1tPlZg-00F8FI-Hn for pgsql-general@arkaria.postgresql.org; Mon, 23 Dec 2024 16:46:33 +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 1tPlZf-00CU85-Sk for pgsql-general@arkaria.postgresql.org; Mon, 23 Dec 2024 16:46:31 +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 1tPlZf-00CU7w-E5 for pgsql-general@lists.postgresql.org; Mon, 23 Dec 2024 16:46:31 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tPlZd-000CsY-2P for pgsql-general@lists.postgresql.org; Mon, 23 Dec 2024 16:46:30 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-29e2a50586dso2045757fac.0 for ; Mon, 23 Dec 2024 08:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734972388; x=1735577188; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=reCUmCPB7Gzkbnfb/ZOQAyEbxrqMgnd25n1f5T308cY=; b=lcL1YbQvma9ttG0xZxH1l88WOiPMxG8NlWHlQxmx9IDM7cHav+61AoPuaW3SCa+C8D xZDIz/r2Fed7J/4aBh8P9YEwotXAIEF2aZBUE3IrqvkGT+kQuHMyf6FnHdaNl0kn1fec HTOC9uGM3Own9VgbN2v4l3BvSQh+fR+HreN17uKMFj28gvDDFcWgBc36KevD1B6wTVxt BDbKNI4c0dbvNy7xPeTcgh7TgBFRDdMieLPQiDQLmkdPY2fdOhs4ctBoBWCIL/uckYMW g1h8etHp3JwAsk6E1ao9y1mgKFDS+TxBuozXLrBAcoDXuITuM3eg4uBP+BDauuqPk0zA o79g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734972388; x=1735577188; h=cc: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=reCUmCPB7Gzkbnfb/ZOQAyEbxrqMgnd25n1f5T308cY=; b=wCrzsnh06gw26RELPvjIej3kuLwS8ACKeDBr117pVqOiaOPZ5smML6SoC5sgrQxeFN KyLr4Uo+qmoorXwpkolpceA8FL1LJXCdTx7aYnESboImupKcQsTRIaALLA3OrjUOE+77 42wnEFrQxoMq0tpYGfmWoj2H0es5hai8HO5N6wXHj2JT5y29NnUfUcJP2LKLq8TPpVNY nTNWWhI4SXdfpaMAxaQrTlOLyBs1Vq8urfxlPOaf/hdKL7kgNI9fTBygRm5wEy8wxzaX 2BHlaIGREKb/XALxyOVHu67KbS7MSi8g46GWMFV/RwJ0dqP+5/9TKCpHWBCIXkod2JRg 4J/w== X-Gm-Message-State: AOJu0YwMPnRwkrmV2OBzNhLkNDtMnd+Jhw1E+0pwRehnRqa1aGqjmjDX 0l0MEA1weUKD3+j/r8ujzFJbv+98btx885E41xsmftWKuXlzX/uFIZGCIK50Aqx50h2wTLQTQvS engZCr8DcdyATeSRhvpCDPeOxz65k63Vd X-Gm-Gg: ASbGncvbhZrJgUDiZyaniQ9YSnTRWRULcJaTjbF/bLizwnbPt4uu0QAtee8bOrvk97C jzo1aiFRJefqRnbOU0bzVN18IziA/1b0T9Zl1eWHvjgfmWxfCc3sLBPDSeaHQJ3IsD+abwe4Y X-Google-Smtp-Source: AGHT+IHF9w8hWQIHtAoNQrHCCNqOahWz3wHweQZIabNtChAYQSIq37ZWRsBtoS16YOGgr+SQpJk6VI2kIHy/nt4DXCc= X-Received: by 2002:a05:6871:d043:b0:29d:c5e8:e41f with SMTP id 586e51a60fabf-2a7fb193533mr7947903fac.5.1734972388319; Mon, 23 Dec 2024 08:46:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Divyansh Gupta JNsThMAudy Date: Mon, 23 Dec 2024 22:16:17 +0530 Message-ID: Subject: Re: Need help in database design To: Adrian Klaver Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000e6c2470629f2bc57" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e6c2470629f2bc57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also as you ask how 50 pairs turns into 50 column so each column will be a key and the value of that key will store inside their respective column for each row On Mon, 23 Dec 2024, 10:14=E2=80=AFpm Divyansh Gupta JNsThMAudy, < ag1567827@gmail.com> wrote: > As per the discussion with other team members they suggested if we store > 50 values for keys in an individual column that will provide better > performance as the data type is native (INT2) on the other hand if we sto= re > all the key value pair in a single JSONB column the performance will > degrade even after applying a GIN index on that however the statement > sounds funny but I want to take everyone openion? > > On Mon, 23 Dec 2024, 10:05=E2=80=AFpm Adrian Klaver, > wrote: > >> On 12/23/24 07:53, Divyansh Gupta JNsThMAudy wrote: >> > Hii Community, >> > >> > I need to provide a support for some functionality for my application >> > for that I need to store 50 key value pair set, so I am in a dilemma, >> > weather I create 50 new columns of int2 data type each column will >> >> This is unclear, I am trying to figure out you go from '50 key value >> pair set' to '50 new columns of int2'. >> >> In other words how 50 pairs turn into 50 columns? >> >> Then there is the question of why 50 keys per row in the first place? >> >> >> > contain value of a specific key or should I go with JSONB data type >> with >> > 50 key value pair, the table on which I am going to do that all >> contains >> > 1 Billion rows of data and have 84 hash partitions, I have gone throug= h >> > multiple articles some of them mentioned it's a good approach to creat= e >> > 50 new columns and some states that creating one JSONB would be best >> > that's why I need your help to move forward, also I am ready to make >> > H-Store instead of JSONB if it provides better performance. >> > Please help me to comes out from that dilemma. >> > >> > Regards, >> > Divyansh Gupta, >> > Database Administrator >> >> -- >> Adrian Klaver >> adrian.klaver@aklaver.com >> >> --000000000000e6c2470629f2bc57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Also as you ask how 50 pairs turns into 50 column so each co= lumn will be a key and the value of that key will store inside their respec= tive column for each row


On Mon, 23 Dec 2024, 10:14=E2=80=AFpm Divyansh Gupta JNsThM= Audy, <ag1567827@gmail.com>= ; wrote:

As per the = discussion with other team members they suggested if we store 50 values for= keys in an individual column that will provide better performance as the d= ata type is native (INT2) on the other hand if we store all the key value p= air in a single JSONB column the performance will degrade even after applyi= ng a GIN index on that however the statement sounds funny but I want to tak= e everyone openion?


On Mon= , 23 Dec 2024, 10:05=E2=80=AFpm Adrian Klaver, <adrian.klaver@akl= aver.com> wrote:
On 12/23/24= 07:53, Divyansh Gupta JNsThMAudy wrote:
> Hii Community,
>
> I need to provide a support for some functionality for my application =
> for that I need to store 50 key value pair set, so I am in a dilemma, =
> weather I create 50 new columns of int2 data type each column will
This is unclear, I am trying to figure out you go from '50 key value pair set' to '50 new columns of int2'.

In other words how 50 pairs turn into 50 columns?

Then there is the question of why 50 keys per row in the first place?


> contain value of a specific key or should I go with JSONB data type wi= th
> 50 key value pair, the table on which I am going to do that all contai= ns
> 1 Billion rows of data and have 84 hash partitions, I have gone throug= h
> multiple articles some of them mentioned it's a good approach to c= reate
> 50 new columns and some states that creating one JSONB would be best <= br> > that's why I need your help to move forward, also I am ready to ma= ke
> H-Store instead of JSONB if it provides better performance.
> Please help me to comes out from that dilemma.
>
> Regards,
> Divyansh Gupta,
> Database Administrator

--
Adrian Klaver
adrian.klaver@aklaver.com

--000000000000e6c2470629f2bc57--