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 1tPlXf-00F80Y-7K for pgsql-general@arkaria.postgresql.org; Mon, 23 Dec 2024 16:44:27 +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 1tPlXe-00CQb2-3c for pgsql-general@arkaria.postgresql.org; Mon, 23 Dec 2024 16:44:25 +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 1tPlXd-00CQau-Oq for pgsql-general@lists.postgresql.org; Mon, 23 Dec 2024 16:44:25 +0000 Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tPlXa-001FKe-Oz for pgsql-general@lists.postgresql.org; Mon, 23 Dec 2024 16:44:24 +0000 Received: by mail-oo1-xc34.google.com with SMTP id 006d021491bc7-5f2e13cb356so1881536eaf.2 for ; Mon, 23 Dec 2024 08:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734972261; x=1735577061; 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=TmITrnmDAChrTmctkhV7tRGT6ThIVjjZ/742Jk2rUxE=; b=Wc8eQ/1SFrF5t23TE7vJ1ffhomHZC5BxfRd/AUBu4T5HcydOE1et1fkWDUBVSKOcgx vPA8IOptPK3114EZiFv++MWdGkvOdMFiwggxK3FFej9ukdY488bw0RSrFtC23X+EmwU1 JqCFPnAVcSVMsZd1WTKdqtpHkqg//VeuQS/P1g2wXd9C8J2uuEbofqLjHXXZGZ1yJfPi 0C/Hc8MUG+l5AeY3Ahuv5RGFHtGPKARY3iiEVHbZEBL6kxDYnUDe5q85DfZIKl7hq4TI TAln9IdRWs7ytTSQJ8rU44QJKK3walsI7+JuRfI060/xSuxarrNQl34OBnLlrO27Nv/B lXeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734972261; x=1735577061; 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=TmITrnmDAChrTmctkhV7tRGT6ThIVjjZ/742Jk2rUxE=; b=r844O+CPIkwte4gpStFP6W1EI4ewgpwwf2GkXbZDSM4JyUl8voIM0hvu7lfIkE6ASE AdhVwql4ZhQXBC1wAPUNbf+LziCA9MT2ilWQMYOgzThyoWEeokpfAKQIceTKDfuU4ERJ HzBD6jYd8I0bIu0iJYxJiRRXA/xUytM8nxw0nhUTyeoXsZKALXuF5Q8j3Qkm8PmkF6OS Xi7Q+YovMjuLEbZQmb2NEh0xEhjupKIc/lDIEQRnEIv6KoNx43tfnf4IXjILOUZgZM+o cTSQRuzoFJ8AEQ/zC1vO+PEnjGGB75V+FAJA5RziKvEG79esPsf1KNm04lyx6VgC8sw1 gVDw== X-Gm-Message-State: AOJu0YzZ7+VIG1V9e2qd+tTfInnd67HpMlAU2A66iRo1RxhsCvh5BSXh 9KE9o6s2LIpDygNFtTDCYTpTmunCiga+P/MbAUeVY0Ae4zBI8ngMXQKo/kh9T9SUDWc4dhRq/9n HMuzbJWJpoujdd3xtTMgg+ExKzCw= X-Gm-Gg: ASbGncuAAqmNcDjRXkRv5/bmNwEnXrzNAhzzLU/FsuRZ1PF2mBk1i2qDItkNzfOSELb H9WSaLLq/IVi+b4nHmtjEAcI23g+Hk+bpIgfMm/pcx3fJuq30gxrno5SeBRW39h21qd/74QyR X-Google-Smtp-Source: AGHT+IGQqoMLXgcig7BAjqtpJpjn9n5b8fmDHtdXso4pciExf3NSwGXBVI7Ad39Ni/7R8e0v6jE3tsokQE0oDAVvg4E= X-Received: by 2002:a05:6820:1a06:b0:5f4:cd65:7618 with SMTP id 006d021491bc7-5f62e704fb0mr7889829eaf.1.1734972260984; Mon, 23 Dec 2024 08:44:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Divyansh Gupta JNsThMAudy Date: Mon, 23 Dec 2024 22:14:09 +0530 Message-ID: Subject: Re: Need help in database design To: Adrian Klaver Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000004fae160629f2b5aa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004fae160629f2b5aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 store 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 wit= h > > 50 key value pair, the table on which I am going to do that all contain= s > > 1 Billion rows of data and have 84 hash partitions, I have gone through > > multiple articles some of them mentioned it's a good approach to create > > 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 > > --0000000000004fae160629f2b5aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As per the discussion with other team members they suggested= if we store 50 values for keys in an individual column that will provide b= etter performance as the data type is native (INT2) on the other hand if we= store 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 soun= ds funny but I want to take everyone openion?


On Mon, 23 Dec 2024, 10:05=E2=80=AFpm Adrian Klaver, <adrian.klaver@aklaver.com>= ; wrote:
On 12/23/24 07:53, Divyans= h 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

--0000000000004fae160629f2b5aa--