public inbox for [email protected]
help / color / mirror / Atom feedRe: Need help in database design
19+ messages / 7 participants
[nested] [flat]
* Re: Need help in database design
@ 2024-12-23 17:29 Divyansh Gupta JNsThMAudy <[email protected]>
0 siblings, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 17:29 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Adrian Klaver <[email protected]>; [email protected]
Values can be updated based on customer actions
All rows won't have all 50 key value pairs always if I make those keys into
columns the rows might have null value on the other hand if it is JSONB
then the key value pair will not be there
Yes in UI customers can search for the key value pairs
During data population the key value pair will be empty array in case of
JSONB column or NULL in case of table columns, later when customer performs
some actions that time the key value pairs will populate and update, based
on what action customer performs.
On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
[email protected]> wrote:
> Let's make it more understandable, here is the table schema with 50
> columns in it
>
> CREATE TABLE dbo.googledocs_tbl (
> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
> userid int8 NOT NULL,
> t1 int4 NULL,
> t2 int4 NULL,
> t3 int4 NULL,
> t4 int4 NULL,
> t5 int4 NULL,
> t6 int4 NULL,
> t7 int4 NULL,
> t8 int4 NULL,
> t9 int4 NULL,
> t10 int4 NULL,
> t11 int4 NULL,
> t12 int4 NULL,
> t13 int4 NULL,
> t14 int4 NULL,
> t15 int4 NULL,
> t16 int4 NULL,
> t17 int4 NULL,
> t18 int4 NULL,
> t19 int4 NULL,
> t20 int4 NULL,
> t21 int4 NULL,
> t22 int4 NULL,
> t23 int4 NULL,
> t24 int4 NULL,
> t25 int4 NULL,
> t26 int4 NULL,
> t27 int4 NULL,
> t28 int4 NULL,
> t29 int4 NULL,
> t30 int4 NULL,
> t31 int4 NULL,
> t32 int4 NULL,
> t33 int4 NULL,
> t34 int4 NULL,
> t35 int4 NULL,
> t36 int4 NULL,
> t37 int4 NULL,
> t38 int4 NULL,
> t39 int4 NULL,
> t40 int4 NULL,
> t41 int4 NULL,
> t42 int4 NULL,
> t43 int4 NULL,
> t44 int4 NULL,
> t45 int4 NULL,
> t46 int4 NULL,
> t47 int4 NULL,
> t48 int4 NULL,
> t49 int4 NULL,
> t50 int4 NULL,
> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
> );
>
> Every time when i query I will query it along with userid
> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
> more key filters if customer applies
>
> On the other hand if I create a single jsonb column the schema will look
> like :
>
> CREATE TABLE dbo.googledocs_tbl (
> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
> userid int8 NOT NULL,
> addons_json jsonb default '{}'::jsonb
> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
> );
>
> and the query would be like
> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
> {t1:2}) or (addons_json @> {t1:3})
> more key filters if customer applies
>
>
>
> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
> [email protected]> wrote:
>
>>
>>
>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>>
>>> So here my question is considering one JSONB column is perfect or
>>> considering 50 columns will be more optimised.
>>>
>> The relational database engine is designed around the column-based
>> approach. Especially if the columns are generally unchanging, combined
>> with using fixed-width data types.
>>
>> David J.
>>
>>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 17:31 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 17:31 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Adrian Klaver <[email protected]>; [email protected]
Empty JSONB by mistake, I wrote array sorry about that
On Mon, 23 Dec 2024, 10:59 pm Divyansh Gupta JNsThMAudy, <
[email protected]> wrote:
> Values can be updated based on customer actions
>
> All rows won't have all 50 key value pairs always if I make those keys
> into columns the rows might have null value on the other hand if it is
> JSONB then the key value pair will not be there
>
> Yes in UI customers can search for the key value pairs
>
> During data population the key value pair will be empty array in case of
> JSONB column or NULL in case of table columns, later when customer performs
> some actions that time the key value pairs will populate and update, based
> on what action customer performs.
>
> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
> [email protected]> wrote:
>
>> Let's make it more understandable, here is the table schema with 50
>> columns in it
>>
>> CREATE TABLE dbo.googledocs_tbl (
>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>> userid int8 NOT NULL,
>> t1 int4 NULL,
>> t2 int4 NULL,
>> t3 int4 NULL,
>> t4 int4 NULL,
>> t5 int4 NULL,
>> t6 int4 NULL,
>> t7 int4 NULL,
>> t8 int4 NULL,
>> t9 int4 NULL,
>> t10 int4 NULL,
>> t11 int4 NULL,
>> t12 int4 NULL,
>> t13 int4 NULL,
>> t14 int4 NULL,
>> t15 int4 NULL,
>> t16 int4 NULL,
>> t17 int4 NULL,
>> t18 int4 NULL,
>> t19 int4 NULL,
>> t20 int4 NULL,
>> t21 int4 NULL,
>> t22 int4 NULL,
>> t23 int4 NULL,
>> t24 int4 NULL,
>> t25 int4 NULL,
>> t26 int4 NULL,
>> t27 int4 NULL,
>> t28 int4 NULL,
>> t29 int4 NULL,
>> t30 int4 NULL,
>> t31 int4 NULL,
>> t32 int4 NULL,
>> t33 int4 NULL,
>> t34 int4 NULL,
>> t35 int4 NULL,
>> t36 int4 NULL,
>> t37 int4 NULL,
>> t38 int4 NULL,
>> t39 int4 NULL,
>> t40 int4 NULL,
>> t41 int4 NULL,
>> t42 int4 NULL,
>> t43 int4 NULL,
>> t44 int4 NULL,
>> t45 int4 NULL,
>> t46 int4 NULL,
>> t47 int4 NULL,
>> t48 int4 NULL,
>> t49 int4 NULL,
>> t50 int4 NULL,
>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>> );
>>
>> Every time when i query I will query it along with userid
>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>> more key filters if customer applies
>>
>> On the other hand if I create a single jsonb column the schema will look
>> like :
>>
>> CREATE TABLE dbo.googledocs_tbl (
>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>> userid int8 NOT NULL,
>> addons_json jsonb default '{}'::jsonb
>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>> );
>>
>> and the query would be like
>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>> {t1:2}) or (addons_json @> {t1:3})
>> more key filters if customer applies
>>
>>
>>
>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>>
>>>> So here my question is considering one JSONB column is perfect or
>>>> considering 50 columns will be more optimised.
>>>>
>>> The relational database engine is designed around the column-based
>>> approach. Especially if the columns are generally unchanging, combined
>>> with using fixed-width data types.
>>>
>>> David J.
>>>
>>>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 17:39 Ron Johnson <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 1 reply; 19+ messages in thread
From: Ron Johnson @ 2024-12-23 17:39 UTC (permalink / raw)
To: pgsql-general
Given what you just wrote, I'd stick with 50 separate t* columns.
Simplifies queries, simplifies updates, and eliminates JSONB conversions.
On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Values can be updated based on customer actions
>
> All rows won't have all 50 key value pairs always if I make those keys
> into columns the rows might have null value on the other hand if it is
> JSONB then the key value pair will not be there
>
> Yes in UI customers can search for the key value pairs
>
> During data population the key value pair will be empty array in case of
> JSONB column or NULL in case of table columns, later when customer performs
> some actions that time the key value pairs will populate and update, based
> on what action customer performs.
>
> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
> [email protected]> wrote:
>
>> Let's make it more understandable, here is the table schema with 50
>> columns in it
>>
>> CREATE TABLE dbo.googledocs_tbl (
>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>> userid int8 NOT NULL,
>> t1 int4 NULL,
>> t2 int4 NULL,
>> t3 int4 NULL,
>> t4 int4 NULL,
>> t5 int4 NULL,
>> t6 int4 NULL,
>> t7 int4 NULL,
>> t8 int4 NULL,
>> t9 int4 NULL,
>> t10 int4 NULL,
>> t11 int4 NULL,
>> t12 int4 NULL,
>> t13 int4 NULL,
>> t14 int4 NULL,
>> t15 int4 NULL,
>> t16 int4 NULL,
>> t17 int4 NULL,
>> t18 int4 NULL,
>> t19 int4 NULL,
>> t20 int4 NULL,
>> t21 int4 NULL,
>> t22 int4 NULL,
>> t23 int4 NULL,
>> t24 int4 NULL,
>> t25 int4 NULL,
>> t26 int4 NULL,
>> t27 int4 NULL,
>> t28 int4 NULL,
>> t29 int4 NULL,
>> t30 int4 NULL,
>> t31 int4 NULL,
>> t32 int4 NULL,
>> t33 int4 NULL,
>> t34 int4 NULL,
>> t35 int4 NULL,
>> t36 int4 NULL,
>> t37 int4 NULL,
>> t38 int4 NULL,
>> t39 int4 NULL,
>> t40 int4 NULL,
>> t41 int4 NULL,
>> t42 int4 NULL,
>> t43 int4 NULL,
>> t44 int4 NULL,
>> t45 int4 NULL,
>> t46 int4 NULL,
>> t47 int4 NULL,
>> t48 int4 NULL,
>> t49 int4 NULL,
>> t50 int4 NULL,
>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>> );
>>
>> Every time when i query I will query it along with userid
>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>> more key filters if customer applies
>>
>> On the other hand if I create a single jsonb column the schema will look
>> like :
>>
>> CREATE TABLE dbo.googledocs_tbl (
>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>> userid int8 NOT NULL,
>> addons_json jsonb default '{}'::jsonb
>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>> );
>>
>> and the query would be like
>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>> {t1:2}) or (addons_json @> {t1:3})
>> more key filters if customer applies
>>
>>
>>
>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>>
>>>> So here my question is considering one JSONB column is perfect or
>>>> considering 50 columns will be more optimised.
>>>>
>>> The relational database engine is designed around the column-based
>>> approach. Especially if the columns are generally unchanging, combined
>>> with using fixed-width data types.
>>>
>>> David J.
>>>
>>>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 17:49 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Ron Johnson <[email protected]>
0 siblings, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 17:49 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
I have one confusion with this design if I opt to create 50 columns I need
to create 50 index which will work with userid index in Bitmap on the other
hand if I create a JSONB column I need to create a single index ?
On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]> wrote:
> Given what you just wrote, I'd stick with 50 separate t* columns.
> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>
> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Values can be updated based on customer actions
>>
>> All rows won't have all 50 key value pairs always if I make those keys
>> into columns the rows might have null value on the other hand if it is
>> JSONB then the key value pair will not be there
>>
>> Yes in UI customers can search for the key value pairs
>>
>> During data population the key value pair will be empty array in case of
>> JSONB column or NULL in case of table columns, later when customer performs
>> some actions that time the key value pairs will populate and update, based
>> on what action customer performs.
>>
>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>> [email protected]> wrote:
>>
>>> Let's make it more understandable, here is the table schema with 50
>>> columns in it
>>>
>>> CREATE TABLE dbo.googledocs_tbl (
>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>> userid int8 NOT NULL,
>>> t1 int4 NULL,
>>> t2 int4 NULL,
>>> t3 int4 NULL,
>>> t4 int4 NULL,
>>> t5 int4 NULL,
>>> t6 int4 NULL,
>>> t7 int4 NULL,
>>> t8 int4 NULL,
>>> t9 int4 NULL,
>>> t10 int4 NULL,
>>> t11 int4 NULL,
>>> t12 int4 NULL,
>>> t13 int4 NULL,
>>> t14 int4 NULL,
>>> t15 int4 NULL,
>>> t16 int4 NULL,
>>> t17 int4 NULL,
>>> t18 int4 NULL,
>>> t19 int4 NULL,
>>> t20 int4 NULL,
>>> t21 int4 NULL,
>>> t22 int4 NULL,
>>> t23 int4 NULL,
>>> t24 int4 NULL,
>>> t25 int4 NULL,
>>> t26 int4 NULL,
>>> t27 int4 NULL,
>>> t28 int4 NULL,
>>> t29 int4 NULL,
>>> t30 int4 NULL,
>>> t31 int4 NULL,
>>> t32 int4 NULL,
>>> t33 int4 NULL,
>>> t34 int4 NULL,
>>> t35 int4 NULL,
>>> t36 int4 NULL,
>>> t37 int4 NULL,
>>> t38 int4 NULL,
>>> t39 int4 NULL,
>>> t40 int4 NULL,
>>> t41 int4 NULL,
>>> t42 int4 NULL,
>>> t43 int4 NULL,
>>> t44 int4 NULL,
>>> t45 int4 NULL,
>>> t46 int4 NULL,
>>> t47 int4 NULL,
>>> t48 int4 NULL,
>>> t49 int4 NULL,
>>> t50 int4 NULL,
>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>> );
>>>
>>> Every time when i query I will query it along with userid
>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>> more key filters if customer applies
>>>
>>> On the other hand if I create a single jsonb column the schema will look
>>> like :
>>>
>>> CREATE TABLE dbo.googledocs_tbl (
>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>> userid int8 NOT NULL,
>>> addons_json jsonb default '{}'::jsonb
>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>> );
>>>
>>> and the query would be like
>>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>>> {t1:2}) or (addons_json @> {t1:3})
>>> more key filters if customer applies
>>>
>>>
>>>
>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>> So here my question is considering one JSONB column is perfect or
>>>>> considering 50 columns will be more optimised.
>>>>>
>>>> The relational database engine is designed around the column-based
>>>> approach. Especially if the columns are generally unchanging, combined
>>>> with using fixed-width data types.
>>>>
>>>> David J.
>>>>
>>>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:08 Adrian Klaver <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: Adrian Klaver @ 2024-12-23 18:08 UTC (permalink / raw)
To: Divyansh Gupta JNsThMAudy <[email protected]>; Ron Johnson <[email protected]>; +Cc: pgsql-general
On 12/23/24 09:49, Divyansh Gupta JNsThMAudy wrote:
> I have one confusion with this design if I opt to create 50 columns I
> need to create 50 index which will work with userid index in Bitmap on
> the other hand if I create a JSONB column I need to create a single index ?
>
There still is the part where you plan to partition this data on some as
not yet fully specified hash.
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:09 Ron Johnson <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 1 reply; 19+ messages in thread
From: Ron Johnson @ 2024-12-23 18:09 UTC (permalink / raw)
To: pgsql-general
If your queries all reference userid, then you only need indices on gdid
and userid.
On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> I have one confusion with this design if I opt to create 50 columns I need
> to create 50 index which will work with userid index in Bitmap on the other
> hand if I create a JSONB column I need to create a single index ?
>
> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
> wrote:
>
>> Given what you just wrote, I'd stick with 50 separate t* columns.
>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>
>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>> Values can be updated based on customer actions
>>>
>>> All rows won't have all 50 key value pairs always if I make those keys
>>> into columns the rows might have null value on the other hand if it is
>>> JSONB then the key value pair will not be there
>>>
>>> Yes in UI customers can search for the key value pairs
>>>
>>> During data population the key value pair will be empty array in case of
>>> JSONB column or NULL in case of table columns, later when customer performs
>>> some actions that time the key value pairs will populate and update, based
>>> on what action customer performs.
>>>
>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>> [email protected]> wrote:
>>>
>>>> Let's make it more understandable, here is the table schema with 50
>>>> columns in it
>>>>
>>>> CREATE TABLE dbo.googledocs_tbl (
>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>> userid int8 NOT NULL,
>>>> t1 int4 NULL,
>>>> t2 int4 NULL,
>>>> t3 int4 NULL,
>>>> t4 int4 NULL,
>>>> t5 int4 NULL,
>>>> t6 int4 NULL,
>>>> t7 int4 NULL,
>>>> t8 int4 NULL,
>>>> t9 int4 NULL,
>>>> t10 int4 NULL,
>>>> t11 int4 NULL,
>>>> t12 int4 NULL,
>>>> t13 int4 NULL,
>>>> t14 int4 NULL,
>>>> t15 int4 NULL,
>>>> t16 int4 NULL,
>>>> t17 int4 NULL,
>>>> t18 int4 NULL,
>>>> t19 int4 NULL,
>>>> t20 int4 NULL,
>>>> t21 int4 NULL,
>>>> t22 int4 NULL,
>>>> t23 int4 NULL,
>>>> t24 int4 NULL,
>>>> t25 int4 NULL,
>>>> t26 int4 NULL,
>>>> t27 int4 NULL,
>>>> t28 int4 NULL,
>>>> t29 int4 NULL,
>>>> t30 int4 NULL,
>>>> t31 int4 NULL,
>>>> t32 int4 NULL,
>>>> t33 int4 NULL,
>>>> t34 int4 NULL,
>>>> t35 int4 NULL,
>>>> t36 int4 NULL,
>>>> t37 int4 NULL,
>>>> t38 int4 NULL,
>>>> t39 int4 NULL,
>>>> t40 int4 NULL,
>>>> t41 int4 NULL,
>>>> t42 int4 NULL,
>>>> t43 int4 NULL,
>>>> t44 int4 NULL,
>>>> t45 int4 NULL,
>>>> t46 int4 NULL,
>>>> t47 int4 NULL,
>>>> t48 int4 NULL,
>>>> t49 int4 NULL,
>>>> t50 int4 NULL,
>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>> );
>>>>
>>>> Every time when i query I will query it along with userid
>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>> more key filters if customer applies
>>>>
>>>> On the other hand if I create a single jsonb column the schema will
>>>> look like :
>>>>
>>>> CREATE TABLE dbo.googledocs_tbl (
>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>> userid int8 NOT NULL,
>>>> addons_json jsonb default '{}'::jsonb
>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>> );
>>>>
>>>> and the query would be like
>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>>>> {t1:2}) or (addons_json @> {t1:3})
>>>> more key filters if customer applies
>>>>
>>>>
>>>>
>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>> considering 50 columns will be more optimised.
>>>>>>
>>>>> The relational database engine is designed around the column-based
>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>> with using fixed-width data types.
>>>>>
>>>>> David J.
>>>>>
>>>>>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:18 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Ron Johnson <[email protected]>
0 siblings, 1 reply; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 18:18 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Adrian, the partition is on userid using hash partition with 84 partitions
Ron, there could be more than 20 Million records possible for a single
userid in that case if I create index on userid only not on other column
the query is taking more than 30 seconds to return the results.
On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]> wrote:
> If your queries all reference userid, then you only need indices on gdid
> and userid.
>
> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> I have one confusion with this design if I opt to create 50 columns I
>> need to create 50 index which will work with userid index in Bitmap on the
>> other hand if I create a JSONB column I need to create a single index ?
>>
>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>> wrote:
>>
>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>
>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>> Values can be updated based on customer actions
>>>>
>>>> All rows won't have all 50 key value pairs always if I make those keys
>>>> into columns the rows might have null value on the other hand if it is
>>>> JSONB then the key value pair will not be there
>>>>
>>>> Yes in UI customers can search for the key value pairs
>>>>
>>>> During data population the key value pair will be empty array in case
>>>> of JSONB column or NULL in case of table columns, later when customer
>>>> performs some actions that time the key value pairs will populate and
>>>> update, based on what action customer performs.
>>>>
>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>> [email protected]> wrote:
>>>>
>>>>> Let's make it more understandable, here is the table schema with 50
>>>>> columns in it
>>>>>
>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>> userid int8 NOT NULL,
>>>>> t1 int4 NULL,
>>>>> t2 int4 NULL,
>>>>> t3 int4 NULL,
>>>>> t4 int4 NULL,
>>>>> t5 int4 NULL,
>>>>> t6 int4 NULL,
>>>>> t7 int4 NULL,
>>>>> t8 int4 NULL,
>>>>> t9 int4 NULL,
>>>>> t10 int4 NULL,
>>>>> t11 int4 NULL,
>>>>> t12 int4 NULL,
>>>>> t13 int4 NULL,
>>>>> t14 int4 NULL,
>>>>> t15 int4 NULL,
>>>>> t16 int4 NULL,
>>>>> t17 int4 NULL,
>>>>> t18 int4 NULL,
>>>>> t19 int4 NULL,
>>>>> t20 int4 NULL,
>>>>> t21 int4 NULL,
>>>>> t22 int4 NULL,
>>>>> t23 int4 NULL,
>>>>> t24 int4 NULL,
>>>>> t25 int4 NULL,
>>>>> t26 int4 NULL,
>>>>> t27 int4 NULL,
>>>>> t28 int4 NULL,
>>>>> t29 int4 NULL,
>>>>> t30 int4 NULL,
>>>>> t31 int4 NULL,
>>>>> t32 int4 NULL,
>>>>> t33 int4 NULL,
>>>>> t34 int4 NULL,
>>>>> t35 int4 NULL,
>>>>> t36 int4 NULL,
>>>>> t37 int4 NULL,
>>>>> t38 int4 NULL,
>>>>> t39 int4 NULL,
>>>>> t40 int4 NULL,
>>>>> t41 int4 NULL,
>>>>> t42 int4 NULL,
>>>>> t43 int4 NULL,
>>>>> t44 int4 NULL,
>>>>> t45 int4 NULL,
>>>>> t46 int4 NULL,
>>>>> t47 int4 NULL,
>>>>> t48 int4 NULL,
>>>>> t49 int4 NULL,
>>>>> t50 int4 NULL,
>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>> );
>>>>>
>>>>> Every time when i query I will query it along with userid
>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>> more key filters if customer applies
>>>>>
>>>>> On the other hand if I create a single jsonb column the schema will
>>>>> look like :
>>>>>
>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>> userid int8 NOT NULL,
>>>>> addons_json jsonb default '{}'::jsonb
>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>> );
>>>>>
>>>>> and the query would be like
>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>>>>> {t1:2}) or (addons_json @> {t1:3})
>>>>> more key filters if customer applies
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>> considering 50 columns will be more optimised.
>>>>>>>
>>>>>> The relational database engine is designed around the column-based
>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>> with using fixed-width data types.
>>>>>>
>>>>>> David J.
>>>>>>
>>>>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:23 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
0 siblings, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 18:23 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Adrian, Please check this out;
PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder
0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION OF dbo.
googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Adrian, the partition is on userid using hash partition with 84 partitions
>
> Ron, there could be more than 20 Million records possible for a single
> userid in that case if I create index on userid only not on other column
> the query is taking more than 30 seconds to return the results.
>
> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
> wrote:
>
>> If your queries all reference userid, then you only need indices on gdid
>> and userid.
>>
>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>> I have one confusion with this design if I opt to create 50 columns I
>>> need to create 50 index which will work with userid index in Bitmap on the
>>> other hand if I create a JSONB column I need to create a single index ?
>>>
>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>> wrote:
>>>
>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>
>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>> Values can be updated based on customer actions
>>>>>
>>>>> All rows won't have all 50 key value pairs always if I make those keys
>>>>> into columns the rows might have null value on the other hand if it is
>>>>> JSONB then the key value pair will not be there
>>>>>
>>>>> Yes in UI customers can search for the key value pairs
>>>>>
>>>>> During data population the key value pair will be empty array in case
>>>>> of JSONB column or NULL in case of table columns, later when customer
>>>>> performs some actions that time the key value pairs will populate and
>>>>> update, based on what action customer performs.
>>>>>
>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Let's make it more understandable, here is the table schema with 50
>>>>>> columns in it
>>>>>>
>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>> userid int8 NOT NULL,
>>>>>> t1 int4 NULL,
>>>>>> t2 int4 NULL,
>>>>>> t3 int4 NULL,
>>>>>> t4 int4 NULL,
>>>>>> t5 int4 NULL,
>>>>>> t6 int4 NULL,
>>>>>> t7 int4 NULL,
>>>>>> t8 int4 NULL,
>>>>>> t9 int4 NULL,
>>>>>> t10 int4 NULL,
>>>>>> t11 int4 NULL,
>>>>>> t12 int4 NULL,
>>>>>> t13 int4 NULL,
>>>>>> t14 int4 NULL,
>>>>>> t15 int4 NULL,
>>>>>> t16 int4 NULL,
>>>>>> t17 int4 NULL,
>>>>>> t18 int4 NULL,
>>>>>> t19 int4 NULL,
>>>>>> t20 int4 NULL,
>>>>>> t21 int4 NULL,
>>>>>> t22 int4 NULL,
>>>>>> t23 int4 NULL,
>>>>>> t24 int4 NULL,
>>>>>> t25 int4 NULL,
>>>>>> t26 int4 NULL,
>>>>>> t27 int4 NULL,
>>>>>> t28 int4 NULL,
>>>>>> t29 int4 NULL,
>>>>>> t30 int4 NULL,
>>>>>> t31 int4 NULL,
>>>>>> t32 int4 NULL,
>>>>>> t33 int4 NULL,
>>>>>> t34 int4 NULL,
>>>>>> t35 int4 NULL,
>>>>>> t36 int4 NULL,
>>>>>> t37 int4 NULL,
>>>>>> t38 int4 NULL,
>>>>>> t39 int4 NULL,
>>>>>> t40 int4 NULL,
>>>>>> t41 int4 NULL,
>>>>>> t42 int4 NULL,
>>>>>> t43 int4 NULL,
>>>>>> t44 int4 NULL,
>>>>>> t45 int4 NULL,
>>>>>> t46 int4 NULL,
>>>>>> t47 int4 NULL,
>>>>>> t48 int4 NULL,
>>>>>> t49 int4 NULL,
>>>>>> t50 int4 NULL,
>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>> );
>>>>>>
>>>>>> Every time when i query I will query it along with userid
>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>> more key filters if customer applies
>>>>>>
>>>>>> On the other hand if I create a single jsonb column the schema will
>>>>>> look like :
>>>>>>
>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
>>>>>> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>> userid int8 NOT NULL,
>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>> );
>>>>>>
>>>>>> and the query would be like
>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @>
>>>>>> {t1:2}) or (addons_json @> {t1:3})
>>>>>> more key filters if customer applies
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>>> considering 50 columns will be more optimised.
>>>>>>>>
>>>>>>> The relational database engine is designed around the column-based
>>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>>> with using fixed-width data types.
>>>>>>>
>>>>>>> David J.
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>> Death to <Redacted>, and butter sauce.
>>>> Don't boil me, I'm still alive.
>>>> <Redacted> lobster!
>>>>
>>>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>>
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:26 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 18:26 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Ron here is the entire table schema FYI, userid is the mandate column on
which filter is always applies:
CREATE TABLE dbo.googledocs_tbl (
gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
userid int8 NOT NULL,
useremail varchar(600) NOT NULL,
title public.citext NULL,
authorname varchar(600) NULL,
authoremail varchar(600) NULL,
updated varchar(300) NOT NULL,
entryid varchar(2000) NOT NULL,
lastmodifiedby varchar(600) NULL,
lastmodifiedbyemail varchar(600) NULL,
"size" varchar(300) NULL,
contenttype varchar(250) NULL,
fileextension varchar(50) NULL,
docfoldername public.citext NULL,
folderresourceid public.citext NULL,
filesize int8 DEFAULT 0 NOT NULL,
retentionstatus int2 DEFAULT 0 NOT NULL,
docfileref int8 NULL,
usid int4 NULL,
archivepath varchar(500) NULL,
createddate timestamp(6) DEFAULT NULL::timestamp without time zone NULL,
zipfilename varchar(100) NULL,
oncreatedat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
onupdateat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
startsnapshot int4 DEFAULT 0 NOT NULL,
currentsnapshot int4 DEFAULT 0 NOT NULL,
dismiss int2 DEFAULT 0 NOT NULL,
checksum varchar NULL,
typeoffile int2 GENERATED ALWAYS AS (
CASE
WHEN authoremail::text = useremail::text THEN 0::smallint
ELSE 1::smallint
END) STORED NOT NULL,
parquetfilename varchar(100) NULL,
metadata_vector tsvector GENERATED ALWAYS AS (to_tsvector('english'::
regconfig, (((((COALESCE(title::character varying, ''::text::character
varying)::text || ' '::text) || (COALESCE(docfoldername::text, ''::text) || '
'::text)) || (COALESCE(authorname, ''::text::character varying)::text || ' '
::text)) || (COALESCE(fileextension, ''::text::character varying)::text || '
'::text)) || (COALESCE(lastmodifiedby, ''::text::character varying)::text
|| ' '::text)) || COALESCE(contenttype, ''::character varying::text::
character varying)::text)) STORED NULL,
isfileencrypted int4 DEFAULT 0 NULL,
addons_json jsonb DEFAULT '{}'::jsonb NULL,
CONSTRAINT googledocs_tbl_clone_pkey PRIMARY KEY (gdid, userid),
CONSTRAINT fk_googledocs_tbl_clone_users_tbl FOREIGN KEY (userid) REFERENCES
dbo.users_tbl(uid) ON DELETE CASCADE
)
PARTITION BY HASH (userid);
On Mon, Dec 23, 2024 at 11:53 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Adrian, Please check this out;
>
> PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
> remainder 0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION
> OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
>
> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Adrian, the partition is on userid using hash partition with 84 partitions
>>
>> Ron, there could be more than 20 Million records possible for a single
>> userid in that case if I create index on userid only not on other column
>> the query is taking more than 30 seconds to return the results.
>>
>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>> wrote:
>>
>>> If your queries all reference userid, then you only need indices on gdid
>>> and userid.
>>>
>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>> I have one confusion with this design if I opt to create 50 columns I
>>>> need to create 50 index which will work with userid index in Bitmap on the
>>>> other hand if I create a JSONB column I need to create a single index ?
>>>>
>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>> wrote:
>>>>
>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>
>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Values can be updated based on customer actions
>>>>>>
>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>> JSONB then the key value pair will not be there
>>>>>>
>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>
>>>>>> During data population the key value pair will be empty array in case
>>>>>> of JSONB column or NULL in case of table columns, later when customer
>>>>>> performs some actions that time the key value pairs will populate and
>>>>>> update, based on what action customer performs.
>>>>>>
>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Let's make it more understandable, here is the table schema with 50
>>>>>>> columns in it
>>>>>>>
>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>> userid int8 NOT NULL,
>>>>>>> t1 int4 NULL,
>>>>>>> t2 int4 NULL,
>>>>>>> t3 int4 NULL,
>>>>>>> t4 int4 NULL,
>>>>>>> t5 int4 NULL,
>>>>>>> t6 int4 NULL,
>>>>>>> t7 int4 NULL,
>>>>>>> t8 int4 NULL,
>>>>>>> t9 int4 NULL,
>>>>>>> t10 int4 NULL,
>>>>>>> t11 int4 NULL,
>>>>>>> t12 int4 NULL,
>>>>>>> t13 int4 NULL,
>>>>>>> t14 int4 NULL,
>>>>>>> t15 int4 NULL,
>>>>>>> t16 int4 NULL,
>>>>>>> t17 int4 NULL,
>>>>>>> t18 int4 NULL,
>>>>>>> t19 int4 NULL,
>>>>>>> t20 int4 NULL,
>>>>>>> t21 int4 NULL,
>>>>>>> t22 int4 NULL,
>>>>>>> t23 int4 NULL,
>>>>>>> t24 int4 NULL,
>>>>>>> t25 int4 NULL,
>>>>>>> t26 int4 NULL,
>>>>>>> t27 int4 NULL,
>>>>>>> t28 int4 NULL,
>>>>>>> t29 int4 NULL,
>>>>>>> t30 int4 NULL,
>>>>>>> t31 int4 NULL,
>>>>>>> t32 int4 NULL,
>>>>>>> t33 int4 NULL,
>>>>>>> t34 int4 NULL,
>>>>>>> t35 int4 NULL,
>>>>>>> t36 int4 NULL,
>>>>>>> t37 int4 NULL,
>>>>>>> t38 int4 NULL,
>>>>>>> t39 int4 NULL,
>>>>>>> t40 int4 NULL,
>>>>>>> t41 int4 NULL,
>>>>>>> t42 int4 NULL,
>>>>>>> t43 int4 NULL,
>>>>>>> t44 int4 NULL,
>>>>>>> t45 int4 NULL,
>>>>>>> t46 int4 NULL,
>>>>>>> t47 int4 NULL,
>>>>>>> t48 int4 NULL,
>>>>>>> t49 int4 NULL,
>>>>>>> t50 int4 NULL,
>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>> );
>>>>>>>
>>>>>>> Every time when i query I will query it along with userid
>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>> more key filters if customer applies
>>>>>>>
>>>>>>> On the other hand if I create a single jsonb column the schema will
>>>>>>> look like :
>>>>>>>
>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>> userid int8 NOT NULL,
>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>> );
>>>>>>>
>>>>>>> and the query would be like
>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>> more key filters if customer applies
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>>>> considering 50 columns will be more optimised.
>>>>>>>>>
>>>>>>>> The relational database engine is designed around the column-based
>>>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>>>> with using fixed-width data types.
>>>>>>>>
>>>>>>>> David J.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> --
>>>>> Death to <Redacted>, and butter sauce.
>>>>> Don't boil me, I'm still alive.
>>>>> <Redacted> lobster!
>>>>>
>>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:27 Ron Johnson <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 1 reply; 19+ messages in thread
From: Ron Johnson @ 2024-12-23 18:27 UTC (permalink / raw)
To: pgsql-general
1. I bet you'd get better performance using RANGE partitioning.
2. Twenty million rows per userid is a *LOT*. No subdivisions (like date
range)?
On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Adrian, Please check this out;
>
> PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
> remainder 0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION
> OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
>
> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Adrian, the partition is on userid using hash partition with 84 partitions
>>
>> Ron, there could be more than 20 Million records possible for a single
>> userid in that case if I create index on userid only not on other column
>> the query is taking more than 30 seconds to return the results.
>>
>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>> wrote:
>>
>>> If your queries all reference userid, then you only need indices on gdid
>>> and userid.
>>>
>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>> I have one confusion with this design if I opt to create 50 columns I
>>>> need to create 50 index which will work with userid index in Bitmap on the
>>>> other hand if I create a JSONB column I need to create a single index ?
>>>>
>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>> wrote:
>>>>
>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>
>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Values can be updated based on customer actions
>>>>>>
>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>> JSONB then the key value pair will not be there
>>>>>>
>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>
>>>>>> During data population the key value pair will be empty array in case
>>>>>> of JSONB column or NULL in case of table columns, later when customer
>>>>>> performs some actions that time the key value pairs will populate and
>>>>>> update, based on what action customer performs.
>>>>>>
>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Let's make it more understandable, here is the table schema with 50
>>>>>>> columns in it
>>>>>>>
>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>> userid int8 NOT NULL,
>>>>>>> t1 int4 NULL,
>>>>>>> t2 int4 NULL,
>>>>>>> t3 int4 NULL,
>>>>>>> t4 int4 NULL,
>>>>>>> t5 int4 NULL,
>>>>>>> t6 int4 NULL,
>>>>>>> t7 int4 NULL,
>>>>>>> t8 int4 NULL,
>>>>>>> t9 int4 NULL,
>>>>>>> t10 int4 NULL,
>>>>>>> t11 int4 NULL,
>>>>>>> t12 int4 NULL,
>>>>>>> t13 int4 NULL,
>>>>>>> t14 int4 NULL,
>>>>>>> t15 int4 NULL,
>>>>>>> t16 int4 NULL,
>>>>>>> t17 int4 NULL,
>>>>>>> t18 int4 NULL,
>>>>>>> t19 int4 NULL,
>>>>>>> t20 int4 NULL,
>>>>>>> t21 int4 NULL,
>>>>>>> t22 int4 NULL,
>>>>>>> t23 int4 NULL,
>>>>>>> t24 int4 NULL,
>>>>>>> t25 int4 NULL,
>>>>>>> t26 int4 NULL,
>>>>>>> t27 int4 NULL,
>>>>>>> t28 int4 NULL,
>>>>>>> t29 int4 NULL,
>>>>>>> t30 int4 NULL,
>>>>>>> t31 int4 NULL,
>>>>>>> t32 int4 NULL,
>>>>>>> t33 int4 NULL,
>>>>>>> t34 int4 NULL,
>>>>>>> t35 int4 NULL,
>>>>>>> t36 int4 NULL,
>>>>>>> t37 int4 NULL,
>>>>>>> t38 int4 NULL,
>>>>>>> t39 int4 NULL,
>>>>>>> t40 int4 NULL,
>>>>>>> t41 int4 NULL,
>>>>>>> t42 int4 NULL,
>>>>>>> t43 int4 NULL,
>>>>>>> t44 int4 NULL,
>>>>>>> t45 int4 NULL,
>>>>>>> t46 int4 NULL,
>>>>>>> t47 int4 NULL,
>>>>>>> t48 int4 NULL,
>>>>>>> t49 int4 NULL,
>>>>>>> t50 int4 NULL,
>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>> );
>>>>>>>
>>>>>>> Every time when i query I will query it along with userid
>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>> more key filters if customer applies
>>>>>>>
>>>>>>> On the other hand if I create a single jsonb column the schema will
>>>>>>> look like :
>>>>>>>
>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>> userid int8 NOT NULL,
>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>> );
>>>>>>>
>>>>>>> and the query would be like
>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>> more key filters if customer applies
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>>>> considering 50 columns will be more optimised.
>>>>>>>>>
>>>>>>>> The relational database engine is designed around the column-based
>>>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>>>> with using fixed-width data types.
>>>>>>>>
>>>>>>>> David J.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> --
>>>>> Death to <Redacted>, and butter sauce.
>>>>> Don't boil me, I'm still alive.
>>>>> <Redacted> lobster!
>>>>>
>>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:29 Ron Johnson <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: Ron Johnson @ 2024-12-23 18:29 UTC (permalink / raw)
To: pgsql-general
Where are the 50 "t* columns?
On Mon, Dec 23, 2024 at 1:26 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Ron here is the entire table schema FYI, userid is the mandate column on
> which filter is always applies:
>
> CREATE TABLE dbo.googledocs_tbl (
>
> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>
> userid int8 NOT NULL,
>
> useremail varchar(600) NOT NULL,
>
> title public.citext NULL,
>
> authorname varchar(600) NULL,
>
> authoremail varchar(600) NULL,
>
> updated varchar(300) NOT NULL,
>
> entryid varchar(2000) NOT NULL,
>
> lastmodifiedby varchar(600) NULL,
>
> lastmodifiedbyemail varchar(600) NULL,
>
> "size" varchar(300) NULL,
>
> contenttype varchar(250) NULL,
>
> fileextension varchar(50) NULL,
>
> docfoldername public.citext NULL,
>
> folderresourceid public.citext NULL,
>
> filesize int8 DEFAULT 0 NOT NULL,
>
> retentionstatus int2 DEFAULT 0 NOT NULL,
>
> docfileref int8 NULL,
>
> usid int4 NULL,
>
> archivepath varchar(500) NULL,
>
> createddate timestamp(6) DEFAULT NULL::timestamp without time zone NULL,
>
> zipfilename varchar(100) NULL,
>
> oncreatedat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
>
> onupdateat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
>
> startsnapshot int4 DEFAULT 0 NOT NULL,
>
> currentsnapshot int4 DEFAULT 0 NOT NULL,
>
> dismiss int2 DEFAULT 0 NOT NULL,
>
> checksum varchar NULL,
>
> typeoffile int2 GENERATED ALWAYS AS (
>
> CASE
>
> WHEN authoremail::text = useremail::text THEN 0::smallint
>
> ELSE 1::smallint
>
> END) STORED NOT NULL,
>
> parquetfilename varchar(100) NULL,
>
> metadata_vector tsvector GENERATED ALWAYS AS (to_tsvector('english'::
> regconfig, (((((COALESCE(title::character varying, ''::text::character
> varying)::text || ' '::text) || (COALESCE(docfoldername::text, ''::text)
> || ' '::text)) || (COALESCE(authorname, ''::text::character varying)::text
> || ' '::text)) || (COALESCE(fileextension, ''::text::character varying)::
> text || ' '::text)) || (COALESCE(lastmodifiedby, ''::text::character
> varying)::text || ' '::text)) || COALESCE(contenttype, ''::character
> varying::text::character varying)::text)) STORED NULL,
>
> isfileencrypted int4 DEFAULT 0 NULL,
>
> addons_json jsonb DEFAULT '{}'::jsonb NULL,
>
> CONSTRAINT googledocs_tbl_clone_pkey PRIMARY KEY (gdid, userid),
>
> CONSTRAINT fk_googledocs_tbl_clone_users_tbl FOREIGN KEY (userid)
> REFERENCES dbo.users_tbl(uid) ON DELETE CASCADE
>
> )
>
> PARTITION BY HASH (userid);
>
> On Mon, Dec 23, 2024 at 11:53 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Adrian, Please check this out;
>>
>> PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
>> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
>> remainder 0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION
>> OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
>>
>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>> Adrian, the partition is on userid using hash partition with 84
>>> partitions
>>>
>>> Ron, there could be more than 20 Million records possible for a single
>>> userid in that case if I create index on userid only not on other column
>>> the query is taking more than 30 seconds to return the results.
>>>
>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>>> wrote:
>>>
>>>> If your queries all reference userid, then you only need indices on
>>>> gdid and userid.
>>>>
>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>> I have one confusion with this design if I opt to create 50 columns I
>>>>> need to create 50 index which will work with userid index in Bitmap on the
>>>>> other hand if I create a JSONB column I need to create a single index ?
>>>>>
>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>
>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Values can be updated based on customer actions
>>>>>>>
>>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>>> JSONB then the key value pair will not be there
>>>>>>>
>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>
>>>>>>> During data population the key value pair will be empty array in
>>>>>>> case of JSONB column or NULL in case of table columns, later when customer
>>>>>>> performs some actions that time the key value pairs will populate and
>>>>>>> update, based on what action customer performs.
>>>>>>>
>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Let's make it more understandable, here is the table schema with 50
>>>>>>>> columns in it
>>>>>>>>
>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>> userid int8 NOT NULL,
>>>>>>>> t1 int4 NULL,
>>>>>>>> t2 int4 NULL,
>>>>>>>>
>>>>>>>> [snip]
> t46 int4 NULL,
>>>>>>>> t47 int4 NULL,
>>>>>>>> t48 int4 NULL,
>>>>>>>> t49 int4 NULL,
>>>>>>>> t50 int4 NULL,
>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>> );
>>>>>>>>
>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>> more key filters if customer applies
>>>>>>>>
>>>>>>>> On the other hand if I create a single jsonb column the schema will
>>>>>>>> look like :
>>>>>>>>
>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>> userid int8 NOT NULL,
>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>> );
>>>>>>>>
>>>>>>>> and the query would be like
>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>>> more key filters if customer applies
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>>>>> considering 50 columns will be more optimised.
>>>>>>>>>>
>>>>>>>>> The relational database engine is designed around the column-based
>>>>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>>>>> with using fixed-width data types.
>>>>>>>>>
>>>>>>>>> David J.
>>>>>>>>>
>>>>>>>>>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:30 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Ron Johnson <[email protected]>
0 siblings, 1 reply; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 18:30 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Range partition can help when you applies filter for a specific range but
in my case I need to apply filter on userid always, however I have date
columns but there is less variation in timestamp which I have that's why
didn't go for range partition.
On Mon, 23 Dec 2024, 11:57 pm Ron Johnson, <[email protected]> wrote:
>
> 1. I bet you'd get better performance using RANGE partitioning.
> 2. Twenty million rows per userid is a *LOT*. No subdivisions (like date
> range)?
>
> On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Adrian, Please check this out;
>>
>> PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
>> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
>> remainder 0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION
>> OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
>>
>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>> Adrian, the partition is on userid using hash partition with 84
>>> partitions
>>>
>>> Ron, there could be more than 20 Million records possible for a single
>>> userid in that case if I create index on userid only not on other column
>>> the query is taking more than 30 seconds to return the results.
>>>
>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>>> wrote:
>>>
>>>> If your queries all reference userid, then you only need indices on
>>>> gdid and userid.
>>>>
>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>> I have one confusion with this design if I opt to create 50 columns I
>>>>> need to create 50 index which will work with userid index in Bitmap on the
>>>>> other hand if I create a JSONB column I need to create a single index ?
>>>>>
>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>
>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Values can be updated based on customer actions
>>>>>>>
>>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>>> JSONB then the key value pair will not be there
>>>>>>>
>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>
>>>>>>> During data population the key value pair will be empty array in
>>>>>>> case of JSONB column or NULL in case of table columns, later when customer
>>>>>>> performs some actions that time the key value pairs will populate and
>>>>>>> update, based on what action customer performs.
>>>>>>>
>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Let's make it more understandable, here is the table schema with 50
>>>>>>>> columns in it
>>>>>>>>
>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>> userid int8 NOT NULL,
>>>>>>>> t1 int4 NULL,
>>>>>>>> t2 int4 NULL,
>>>>>>>> t3 int4 NULL,
>>>>>>>> t4 int4 NULL,
>>>>>>>> t5 int4 NULL,
>>>>>>>> t6 int4 NULL,
>>>>>>>> t7 int4 NULL,
>>>>>>>> t8 int4 NULL,
>>>>>>>> t9 int4 NULL,
>>>>>>>> t10 int4 NULL,
>>>>>>>> t11 int4 NULL,
>>>>>>>> t12 int4 NULL,
>>>>>>>> t13 int4 NULL,
>>>>>>>> t14 int4 NULL,
>>>>>>>> t15 int4 NULL,
>>>>>>>> t16 int4 NULL,
>>>>>>>> t17 int4 NULL,
>>>>>>>> t18 int4 NULL,
>>>>>>>> t19 int4 NULL,
>>>>>>>> t20 int4 NULL,
>>>>>>>> t21 int4 NULL,
>>>>>>>> t22 int4 NULL,
>>>>>>>> t23 int4 NULL,
>>>>>>>> t24 int4 NULL,
>>>>>>>> t25 int4 NULL,
>>>>>>>> t26 int4 NULL,
>>>>>>>> t27 int4 NULL,
>>>>>>>> t28 int4 NULL,
>>>>>>>> t29 int4 NULL,
>>>>>>>> t30 int4 NULL,
>>>>>>>> t31 int4 NULL,
>>>>>>>> t32 int4 NULL,
>>>>>>>> t33 int4 NULL,
>>>>>>>> t34 int4 NULL,
>>>>>>>> t35 int4 NULL,
>>>>>>>> t36 int4 NULL,
>>>>>>>> t37 int4 NULL,
>>>>>>>> t38 int4 NULL,
>>>>>>>> t39 int4 NULL,
>>>>>>>> t40 int4 NULL,
>>>>>>>> t41 int4 NULL,
>>>>>>>> t42 int4 NULL,
>>>>>>>> t43 int4 NULL,
>>>>>>>> t44 int4 NULL,
>>>>>>>> t45 int4 NULL,
>>>>>>>> t46 int4 NULL,
>>>>>>>> t47 int4 NULL,
>>>>>>>> t48 int4 NULL,
>>>>>>>> t49 int4 NULL,
>>>>>>>> t50 int4 NULL,
>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>> );
>>>>>>>>
>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>> more key filters if customer applies
>>>>>>>>
>>>>>>>> On the other hand if I create a single jsonb column the schema will
>>>>>>>> look like :
>>>>>>>>
>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE
>>>>>>>> 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>> userid int8 NOT NULL,
>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>> );
>>>>>>>>
>>>>>>>> and the query would be like
>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>>> more key filters if customer applies
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So here my question is considering one JSONB column is perfect or
>>>>>>>>>> considering 50 columns will be more optimised.
>>>>>>>>>>
>>>>>>>>> The relational database engine is designed around the column-based
>>>>>>>>> approach. Especially if the columns are generally unchanging, combined
>>>>>>>>> with using fixed-width data types.
>>>>>>>>>
>>>>>>>>> David J.
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Death to <Redacted>, and butter sauce.
>>>>>> Don't boil me, I'm still alive.
>>>>>> <Redacted> lobster!
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Death to <Redacted>, and butter sauce.
>>>> Don't boil me, I'm still alive.
>>>> <Redacted> lobster!
>>>>
>>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:31 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
0 siblings, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 18:31 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Currently I haven't created those columns , I have created addons_json
column which is a JSONB column yet in a discussion weather I should create
or consider only one JSONB column.
On Tue, 24 Dec 2024, 12:00 am Divyansh Gupta JNsThMAudy, <
[email protected]> wrote:
> Range partition can help when you applies filter for a specific range but
> in my case I need to apply filter on userid always, however I have date
> columns but there is less variation in timestamp which I have that's why
> didn't go for range partition.
>
> On Mon, 23 Dec 2024, 11:57 pm Ron Johnson, <[email protected]>
> wrote:
>
>>
>> 1. I bet you'd get better performance using RANGE partitioning.
>> 2. Twenty million rows per userid is a *LOT*. No subdivisions (like
>> date range)?
>>
>> On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <
>> [email protected]> wrote:
>>
>>> Adrian, Please check this out;
>>>
>>> PARTITION BY HASH (userid); CREATE TABLE dbo.googledocs_tbl_clone_part_0
>>> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
>>> remainder 0); ... CREATE TABLE dbo.googledocs_tbl_clone_part_83
>>> PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84,
>>> remainder 83);
>>>
>>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>> Adrian, the partition is on userid using hash partition with 84
>>>> partitions
>>>>
>>>> Ron, there could be more than 20 Million records possible for a single
>>>> userid in that case if I create index on userid only not on other column
>>>> the query is taking more than 30 seconds to return the results.
>>>>
>>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>>>> wrote:
>>>>
>>>>> If your queries all reference userid, then you only need indices on
>>>>> gdid and userid.
>>>>>
>>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I have one confusion with this design if I opt to create 50 columns I
>>>>>> need to create 50 index which will work with userid index in Bitmap on the
>>>>>> other hand if I create a JSONB column I need to create a single index ?
>>>>>>
>>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>>
>>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Values can be updated based on customer actions
>>>>>>>>
>>>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>>>> JSONB then the key value pair will not be there
>>>>>>>>
>>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>>
>>>>>>>> During data population the key value pair will be empty array in
>>>>>>>> case of JSONB column or NULL in case of table columns, later when customer
>>>>>>>> performs some actions that time the key value pairs will populate and
>>>>>>>> update, based on what action customer performs.
>>>>>>>>
>>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Let's make it more understandable, here is the table schema with
>>>>>>>>> 50 columns in it
>>>>>>>>>
>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>> t1 int4 NULL,
>>>>>>>>> t2 int4 NULL,
>>>>>>>>> t3 int4 NULL,
>>>>>>>>> t4 int4 NULL,
>>>>>>>>> t5 int4 NULL,
>>>>>>>>> t6 int4 NULL,
>>>>>>>>> t7 int4 NULL,
>>>>>>>>> t8 int4 NULL,
>>>>>>>>> t9 int4 NULL,
>>>>>>>>> t10 int4 NULL,
>>>>>>>>> t11 int4 NULL,
>>>>>>>>> t12 int4 NULL,
>>>>>>>>> t13 int4 NULL,
>>>>>>>>> t14 int4 NULL,
>>>>>>>>> t15 int4 NULL,
>>>>>>>>> t16 int4 NULL,
>>>>>>>>> t17 int4 NULL,
>>>>>>>>> t18 int4 NULL,
>>>>>>>>> t19 int4 NULL,
>>>>>>>>> t20 int4 NULL,
>>>>>>>>> t21 int4 NULL,
>>>>>>>>> t22 int4 NULL,
>>>>>>>>> t23 int4 NULL,
>>>>>>>>> t24 int4 NULL,
>>>>>>>>> t25 int4 NULL,
>>>>>>>>> t26 int4 NULL,
>>>>>>>>> t27 int4 NULL,
>>>>>>>>> t28 int4 NULL,
>>>>>>>>> t29 int4 NULL,
>>>>>>>>> t30 int4 NULL,
>>>>>>>>> t31 int4 NULL,
>>>>>>>>> t32 int4 NULL,
>>>>>>>>> t33 int4 NULL,
>>>>>>>>> t34 int4 NULL,
>>>>>>>>> t35 int4 NULL,
>>>>>>>>> t36 int4 NULL,
>>>>>>>>> t37 int4 NULL,
>>>>>>>>> t38 int4 NULL,
>>>>>>>>> t39 int4 NULL,
>>>>>>>>> t40 int4 NULL,
>>>>>>>>> t41 int4 NULL,
>>>>>>>>> t42 int4 NULL,
>>>>>>>>> t43 int4 NULL,
>>>>>>>>> t44 int4 NULL,
>>>>>>>>> t45 int4 NULL,
>>>>>>>>> t46 int4 NULL,
>>>>>>>>> t47 int4 NULL,
>>>>>>>>> t48 int4 NULL,
>>>>>>>>> t49 int4 NULL,
>>>>>>>>> t50 int4 NULL,
>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>> );
>>>>>>>>>
>>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>>> more key filters if customer applies
>>>>>>>>>
>>>>>>>>> On the other hand if I create a single jsonb column the schema
>>>>>>>>> will look like :
>>>>>>>>>
>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>> );
>>>>>>>>>
>>>>>>>>> and the query would be like
>>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>>>> more key filters if customer applies
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So here my question is considering one JSONB column is perfect
>>>>>>>>>>> or considering 50 columns will be more optimised.
>>>>>>>>>>>
>>>>>>>>>> The relational database engine is designed around the
>>>>>>>>>> column-based approach. Especially if the columns are generally unchanging,
>>>>>>>>>> combined with using fixed-width data types.
>>>>>>>>>>
>>>>>>>>>> David J.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Death to <Redacted>, and butter sauce.
>>>>>>> Don't boil me, I'm still alive.
>>>>>>> <Redacted> lobster!
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Death to <Redacted>, and butter sauce.
>>>>> Don't boil me, I'm still alive.
>>>>> <Redacted> lobster!
>>>>>
>>>>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>>
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:34 Arnold Morein <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: Arnold Morein @ 2024-12-23 18:34 UTC (permalink / raw)
To: Divyansh Gupta JNsThMAudy <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
I would like to make a suggestion, if I may. Granted, I do not understand the underlying task at hand, but:
A table with multiple columns of the same type smacks of designs that harken back to the days of mainframes. (STOP THAT!) The data described is a non-normalized array of integers that is meaningless outside of code. Table structures should be at least a LITTLE self-descriptive.
It is also not flexible (what if you suddenly need t51? how long would that table space adjustment take in production?) and space is wasted if not all 50 columns are populated.
Use a design that is basically a storage area for name/value pairs:
create table dbo.googledocs_tbl (
id long identity primary key, — easy way to access a single record
owner_id integer/long not null, — fk to owning parent record in other table such as user
owner_type char(2), — optional field, identifies the owing table, makes this table even more generic
property_name varchar(n) not null, — required unique name for property, not an array reference (t1, t4, t50)
— the names are controlled by the developer but should be human interpretable which can then be used in queries
property_value int4 not null — the important value in question
);
The fields owner_id, owner_type, property_name become a tertiary key that can never be changed, are unique and easily accessible via index lookup.
Add a timestamp if need be
You could then partition the record by owner_type or owner_id or whatever else comes to mind.
Then you just have to figure out the best way to index this monster for optimized queries.
> On Dec 23, 2024, at 12:31 PM, Divyansh Gupta JNsThMAudy <[email protected]> wrote:
>
> Currently I haven't created those columns , I have created addons_json column which is a JSONB column yet in a discussion weather I should create or consider only one JSONB column.
>
>
> On Tue, 24 Dec 2024, 12:00 am Divyansh Gupta JNsThMAudy, <[email protected] <mailto:[email protected]>> wrote:
>> Range partition can help when you applies filter for a specific range but in my case I need to apply filter on userid always, however I have date columns but there is less variation in timestamp which I have that's why didn't go for range partition.
>>
>>
>> On Mon, 23 Dec 2024, 11:57 pm Ron Johnson, <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> 1. I bet you'd get better performance using RANGE partitioning.
>>> 2. Twenty million rows per userid is a LOT. No subdivisions (like date range)?
>>>
>>> On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <[email protected] <mailto:[email protected]>> wrote:
>>>> Adrian, Please check this out;
>>>>
>>>> PARTITION BY HASH (userid);
>>>> CREATE TABLE dbo.googledocs_tbl_clone_part_0 PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 0);
>>>> ...
>>>> CREATE TABLE dbo.googledocs_tbl_clone_part_83 PARTITION OF dbo.googledocs_tbl_clone FOR VALUES WITH (modulus 84, remainder 83);
>>>>
>>>>
>>>>
>>>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <[email protected] <mailto:[email protected]>> wrote:
>>>>> Adrian, the partition is on userid using hash partition with 84 partitions
>>>>>
>>>>> Ron, there could be more than 20 Million records possible for a single userid in that case if I create index on userid only not on other column the query is taking more than 30 seconds to return the results.
>>>>>
>>>>>
>>>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected] <mailto:[email protected]>> wrote:
>>>>>> If your queries all reference userid, then you only need indices on gdid and userid.
>>>>>>
>>>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <[email protected] <mailto:[email protected]>> wrote:
>>>>>>> I have one confusion with this design if I opt to create 50 columns I need to create 50 index which will work with userid index in Bitmap on the other hand if I create a JSONB column I need to create a single index ?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns. Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>> Values can be updated based on customer actions
>>>>>>>>>
>>>>>>>>> All rows won't have all 50 key value pairs always if I make those keys into columns the rows might have null value on the other hand if it is JSONB then the key value pair will not be there
>>>>>>>>>
>>>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>>>
>>>>>>>>> During data population the key value pair will be empty array in case of JSONB column or NULL in case of table columns, later when customer performs some actions that time the key value pairs will populate and update, based on what action customer performs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>>> Let's make it more understandable, here is the table schema with 50 columns in it
>>>>>>>>>>
>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>> t1 int4 NULL,
>>>>>>>>>> t2 int4 NULL,
>>>>>>>>>> t3 int4 NULL,
>>>>>>>>>> t4 int4 NULL,
>>>>>>>>>> t5 int4 NULL,
>>>>>>>>>> t6 int4 NULL,
>>>>>>>>>> t7 int4 NULL,
>>>>>>>>>> t8 int4 NULL,
>>>>>>>>>> t9 int4 NULL,
>>>>>>>>>> t10 int4 NULL,
>>>>>>>>>> t11 int4 NULL,
>>>>>>>>>> t12 int4 NULL,
>>>>>>>>>> t13 int4 NULL,
>>>>>>>>>> t14 int4 NULL,
>>>>>>>>>> t15 int4 NULL,
>>>>>>>>>> t16 int4 NULL,
>>>>>>>>>> t17 int4 NULL,
>>>>>>>>>> t18 int4 NULL,
>>>>>>>>>> t19 int4 NULL,
>>>>>>>>>> t20 int4 NULL,
>>>>>>>>>> t21 int4 NULL,
>>>>>>>>>> t22 int4 NULL,
>>>>>>>>>> t23 int4 NULL,
>>>>>>>>>> t24 int4 NULL,
>>>>>>>>>> t25 int4 NULL,
>>>>>>>>>> t26 int4 NULL,
>>>>>>>>>> t27 int4 NULL,
>>>>>>>>>> t28 int4 NULL,
>>>>>>>>>> t29 int4 NULL,
>>>>>>>>>> t30 int4 NULL,
>>>>>>>>>> t31 int4 NULL,
>>>>>>>>>> t32 int4 NULL,
>>>>>>>>>> t33 int4 NULL,
>>>>>>>>>> t34 int4 NULL,
>>>>>>>>>> t35 int4 NULL,
>>>>>>>>>> t36 int4 NULL,
>>>>>>>>>> t37 int4 NULL,
>>>>>>>>>> t38 int4 NULL,
>>>>>>>>>> t39 int4 NULL,
>>>>>>>>>> t40 int4 NULL,
>>>>>>>>>> t41 int4 NULL,
>>>>>>>>>> t42 int4 NULL,
>>>>>>>>>> t43 int4 NULL,
>>>>>>>>>> t44 int4 NULL,
>>>>>>>>>> t45 int4 NULL,
>>>>>>>>>> t46 int4 NULL,
>>>>>>>>>> t47 int4 NULL,
>>>>>>>>>> t48 int4 NULL,
>>>>>>>>>> t49 int4 NULL,
>>>>>>>>>> t50 int4 NULL,
>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>> );
>>>>>>>>>>
>>>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>
>>>>>>>>>> On the other hand if I create a single jsonb column the schema will look like :
>>>>>>>>>>
>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>> );
>>>>>>>>>>
>>>>>>>>>> and the query would be like
>>>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or (addons_json @> {t1:2}) or <> (addons_json @> {t1:3})
>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <>
>>>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> So here my question is considering one JSONB column is perfect or considering 50 columns will be more optimised.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The relational database engine is designed around the column-based approach. Especially if the columns are generally unchanging, combined with using fixed-width data types.
>>>>>>>>>>>
>>>>>>>>>>> David J.
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Death to <Redacted>, and butter sauce.
>>>>>>>> Don't boil me, I'm still alive.
>>>>>>>> <Redacted> lobster!
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Death to <Redacted>, and butter sauce.
>>>>>> Don't boil me, I'm still alive.
>>>>>> <Redacted> lobster!
>>>
>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 18:38 Ron Johnson <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 1 reply; 19+ messages in thread
From: Ron Johnson @ 2024-12-23 18:38 UTC (permalink / raw)
To: pgsql-general
Are these columns really unique for all 20M rows that a userid can have in
the table? I'm dubious.
Split a LOT of those columns out into a separate table named "user" with PK
userid. It'll save a huge amount of disk space, and speed up queries by
not having to fetch it all every time.
useremail varchar(600) NOT NULL,
title public.citext NULL,
authorname varchar(600) NULL,
authoremail varchar(600) NULL,
updated varchar(300) NOT NULL,
entryid varchar(2000) NOT NULL,
lastmodifiedby varchar(600) NULL,
lastmodifiedbyemail varchar(600) NULL,
"size" varchar(300) NULL,
contenttype varchar(250) NULL,
fileextension varchar(50) NULL,
docfoldername public.citext NULL,
folderresourceid public.citext NULL,
filesize int8 DEFAULT 0 NOT NULL,
retentionstatus int2 DEFAULT 0 NOT NULL,
docfileref int8 NULL,
usid int4 NULL,
archivepath varchar(500) NULL,
createddate timestamp(6) DEFAULT NULL::timestamp without time zone NULL,
zipfilename varchar(100) NULL,
oncreatedat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
onupdateat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
startsnapshot int4 DEFAULT 0 NOT NULL,
currentsnapshot int4 DEFAULT 0 NOT NULL,
dismiss int2 DEFAULT 0 NOT NULL,
checksum varchar NULL,
typeoffile int2 GENERATED ALWAYS AS (
On Mon, Dec 23, 2024 at 1:32 PM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
> Currently I haven't created those columns , I have created addons_json
> column which is a JSONB column yet in a discussion weather I should create
> or consider only one JSONB column.
>
> On Tue, 24 Dec 2024, 12:00 am Divyansh Gupta JNsThMAudy, <
> [email protected]> wrote:
>
>> Range partition can help when you applies filter for a specific range but
>> in my case I need to apply filter on userid always, however I have date
>> columns but there is less variation in timestamp which I have that's why
>> didn't go for range partition.
>>
>> On Mon, 23 Dec 2024, 11:57 pm Ron Johnson, <[email protected]>
>> wrote:
>>
>>>
>>> 1. I bet you'd get better performance using RANGE partitioning.
>>> 2. Twenty million rows per userid is a *LOT*. No subdivisions (like
>>> date range)?
>>>
>>> On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <
>>> [email protected]> wrote:
>>>
>>>> Adrian, Please check this out;
>>>>
>>>> PARTITION BY HASH (userid); CREATE TABLE dbo.
>>>> googledocs_tbl_clone_part_0 PARTITION OF dbo.googledocs_tbl_clone FOR
>>>> VALUES WITH (modulus 84, remainder 0); ... CREATE TABLE dbo.
>>>> googledocs_tbl_clone_part_83 PARTITION OF dbo.googledocs_tbl_clone FOR
>>>> VALUES WITH (modulus 84, remainder 83);
>>>>
>>>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>> Adrian, the partition is on userid using hash partition with 84
>>>>> partitions
>>>>>
>>>>> Ron, there could be more than 20 Million records possible for a single
>>>>> userid in that case if I create index on userid only not on other column
>>>>> the query is taking more than 30 seconds to return the results.
>>>>>
>>>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> If your queries all reference userid, then you only need indices on
>>>>>> gdid and userid.
>>>>>>
>>>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> I have one confusion with this design if I opt to create 50 columns
>>>>>>> I need to create 50 index which will work with userid index in Bitmap on
>>>>>>> the other hand if I create a JSONB column I need to create a single index ?
>>>>>>>
>>>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>>>
>>>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Values can be updated based on customer actions
>>>>>>>>>
>>>>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>>>>> JSONB then the key value pair will not be there
>>>>>>>>>
>>>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>>>
>>>>>>>>> During data population the key value pair will be empty array in
>>>>>>>>> case of JSONB column or NULL in case of table columns, later when customer
>>>>>>>>> performs some actions that time the key value pairs will populate and
>>>>>>>>> update, based on what action customer performs.
>>>>>>>>>
>>>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Let's make it more understandable, here is the table schema with
>>>>>>>>>> 50 columns in it
>>>>>>>>>>
>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>> t1 int4 NULL,
>>>>>>>>>> t2 int4 NULL,
>>>>>>>>>> t3 int4 NULL,
>>>>>>>>>> t4 int4 NULL,
>>>>>>>>>> t5 int4 NULL,
>>>>>>>>>> t6 int4 NULL,
>>>>>>>>>> t7 int4 NULL,
>>>>>>>>>> t8 int4 NULL,
>>>>>>>>>> t9 int4 NULL,
>>>>>>>>>> t10 int4 NULL,
>>>>>>>>>> t11 int4 NULL,
>>>>>>>>>> t12 int4 NULL,
>>>>>>>>>> t13 int4 NULL,
>>>>>>>>>> t14 int4 NULL,
>>>>>>>>>> t15 int4 NULL,
>>>>>>>>>> t16 int4 NULL,
>>>>>>>>>> t17 int4 NULL,
>>>>>>>>>> t18 int4 NULL,
>>>>>>>>>> t19 int4 NULL,
>>>>>>>>>> t20 int4 NULL,
>>>>>>>>>> t21 int4 NULL,
>>>>>>>>>> t22 int4 NULL,
>>>>>>>>>> t23 int4 NULL,
>>>>>>>>>> t24 int4 NULL,
>>>>>>>>>> t25 int4 NULL,
>>>>>>>>>> t26 int4 NULL,
>>>>>>>>>> t27 int4 NULL,
>>>>>>>>>> t28 int4 NULL,
>>>>>>>>>> t29 int4 NULL,
>>>>>>>>>> t30 int4 NULL,
>>>>>>>>>> t31 int4 NULL,
>>>>>>>>>> t32 int4 NULL,
>>>>>>>>>> t33 int4 NULL,
>>>>>>>>>> t34 int4 NULL,
>>>>>>>>>> t35 int4 NULL,
>>>>>>>>>> t36 int4 NULL,
>>>>>>>>>> t37 int4 NULL,
>>>>>>>>>> t38 int4 NULL,
>>>>>>>>>> t39 int4 NULL,
>>>>>>>>>> t40 int4 NULL,
>>>>>>>>>> t41 int4 NULL,
>>>>>>>>>> t42 int4 NULL,
>>>>>>>>>> t43 int4 NULL,
>>>>>>>>>> t44 int4 NULL,
>>>>>>>>>> t45 int4 NULL,
>>>>>>>>>> t46 int4 NULL,
>>>>>>>>>> t47 int4 NULL,
>>>>>>>>>> t48 int4 NULL,
>>>>>>>>>> t49 int4 NULL,
>>>>>>>>>> t50 int4 NULL,
>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>> );
>>>>>>>>>>
>>>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>
>>>>>>>>>> On the other hand if I create a single jsonb column the schema
>>>>>>>>>> will look like :
>>>>>>>>>>
>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>> );
>>>>>>>>>>
>>>>>>>>>> and the query would be like
>>>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So here my question is considering one JSONB column is perfect
>>>>>>>>>>>> or considering 50 columns will be more optimised.
>>>>>>>>>>>>
>>>>>>>>>>> The relational database engine is designed around the
>>>>>>>>>>> column-based approach. Especially if the columns are generally unchanging,
>>>>>>>>>>> combined with using fixed-width data types.
>>>>>>>>>>>
>>>>>>>>>>> David J.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Death to <Redacted>, and butter sauce.
>>>>>>>> Don't boil me, I'm still alive.
>>>>>>>> <Redacted> lobster!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Death to <Redacted>, and butter sauce.
>>>>>> Don't boil me, I'm still alive.
>>>>>> <Redacted> lobster!
>>>>>>
>>>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 19:11 Divyansh Gupta JNsThMAudy <[email protected]>
parent: Ron Johnson <[email protected]>
0 siblings, 2 replies; 19+ messages in thread
From: Divyansh Gupta JNsThMAudy @ 2024-12-23 19:11 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Thank you everyone for giving your valuable responses, I am glad that
everyone understands my concern. I got some good ideas about the database
design that I am following after going through some stress testing I will
implement the same.
Thank you so much Everyone
On Tue, 24 Dec 2024, 12:09 am Ron Johnson, <[email protected]> wrote:
> Are these columns really unique for all 20M rows that a userid can have in
> the table? I'm dubious.
>
> Split a LOT of those columns out into a separate table named "user" with
> PK userid. It'll save a huge amount of disk space, and speed up queries by
> not having to fetch it all every time.
>
> useremail varchar(600) NOT NULL,
> title public.citext NULL,
> authorname varchar(600) NULL,
> authoremail varchar(600) NULL,
> updated varchar(300) NOT NULL,
> entryid varchar(2000) NOT NULL,
> lastmodifiedby varchar(600) NULL,
> lastmodifiedbyemail varchar(600) NULL,
> "size" varchar(300) NULL,
> contenttype varchar(250) NULL,
> fileextension varchar(50) NULL,
> docfoldername public.citext NULL,
> folderresourceid public.citext NULL,
> filesize int8 DEFAULT 0 NOT NULL,
> retentionstatus int2 DEFAULT 0 NOT NULL,
> docfileref int8 NULL,
> usid int4 NULL,
> archivepath varchar(500) NULL,
> createddate timestamp(6) DEFAULT NULL::timestamp without time zone NULL,
> zipfilename varchar(100) NULL,
> oncreatedat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
> onupdateat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
> startsnapshot int4 DEFAULT 0 NOT NULL,
> currentsnapshot int4 DEFAULT 0 NOT NULL,
> dismiss int2 DEFAULT 0 NOT NULL,
> checksum varchar NULL,
> typeoffile int2 GENERATED ALWAYS AS (
>
>
>
> On Mon, Dec 23, 2024 at 1:32 PM Divyansh Gupta JNsThMAudy <
> [email protected]> wrote:
>
>> Currently I haven't created those columns , I have created addons_json
>> column which is a JSONB column yet in a discussion weather I should create
>> or consider only one JSONB column.
>>
>> On Tue, 24 Dec 2024, 12:00 am Divyansh Gupta JNsThMAudy, <
>> [email protected]> wrote:
>>
>>> Range partition can help when you applies filter for a specific range
>>> but in my case I need to apply filter on userid always, however I have date
>>> columns but there is less variation in timestamp which I have that's why
>>> didn't go for range partition.
>>>
>>> On Mon, 23 Dec 2024, 11:57 pm Ron Johnson, <[email protected]>
>>> wrote:
>>>
>>>>
>>>> 1. I bet you'd get better performance using RANGE partitioning.
>>>> 2. Twenty million rows per userid is a *LOT*. No subdivisions (like
>>>> date range)?
>>>>
>>>> On Mon, Dec 23, 2024 at 1:23 PM Divyansh Gupta JNsThMAudy <
>>>> [email protected]> wrote:
>>>>
>>>>> Adrian, Please check this out;
>>>>>
>>>>> PARTITION BY HASH (userid); CREATE TABLE dbo.
>>>>> googledocs_tbl_clone_part_0 PARTITION OF dbo.googledocs_tbl_clone FOR
>>>>> VALUES WITH (modulus 84, remainder 0); ... CREATE TABLE dbo.
>>>>> googledocs_tbl_clone_part_83 PARTITION OF dbo.googledocs_tbl_clone FOR
>>>>> VALUES WITH (modulus 84, remainder 83);
>>>>>
>>>>> On Mon, Dec 23, 2024 at 11:48 PM Divyansh Gupta JNsThMAudy <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Adrian, the partition is on userid using hash partition with 84
>>>>>> partitions
>>>>>>
>>>>>> Ron, there could be more than 20 Million records possible for a
>>>>>> single userid in that case if I create index on userid only not on other
>>>>>> column the query is taking more than 30 seconds to return the results.
>>>>>>
>>>>>> On Mon, 23 Dec 2024, 11:40 pm Ron Johnson, <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> If your queries all reference userid, then you only need indices on
>>>>>>> gdid and userid.
>>>>>>>
>>>>>>> On Mon, Dec 23, 2024 at 12:49 PM Divyansh Gupta JNsThMAudy <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> I have one confusion with this design if I opt to create 50 columns
>>>>>>>> I need to create 50 index which will work with userid index in Bitmap on
>>>>>>>> the other hand if I create a JSONB column I need to create a single index ?
>>>>>>>>
>>>>>>>> On Mon, 23 Dec 2024, 11:10 pm Ron Johnson, <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Given what you just wrote, I'd stick with 50 separate t* columns.
>>>>>>>>> Simplifies queries, simplifies updates, and eliminates JSONB conversions.
>>>>>>>>>
>>>>>>>>> On Mon, Dec 23, 2024 at 12:29 PM Divyansh Gupta JNsThMAudy <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Values can be updated based on customer actions
>>>>>>>>>>
>>>>>>>>>> All rows won't have all 50 key value pairs always if I make those
>>>>>>>>>> keys into columns the rows might have null value on the other hand if it is
>>>>>>>>>> JSONB then the key value pair will not be there
>>>>>>>>>>
>>>>>>>>>> Yes in UI customers can search for the key value pairs
>>>>>>>>>>
>>>>>>>>>> During data population the key value pair will be empty array in
>>>>>>>>>> case of JSONB column or NULL in case of table columns, later when customer
>>>>>>>>>> performs some actions that time the key value pairs will populate and
>>>>>>>>>> update, based on what action customer performs.
>>>>>>>>>>
>>>>>>>>>> On Mon, 23 Dec 2024, 10:51 pm Divyansh Gupta JNsThMAudy, <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Let's make it more understandable, here is the table schema with
>>>>>>>>>>> 50 columns in it
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>>> t1 int4 NULL,
>>>>>>>>>>> t2 int4 NULL,
>>>>>>>>>>> t3 int4 NULL,
>>>>>>>>>>> t4 int4 NULL,
>>>>>>>>>>> t5 int4 NULL,
>>>>>>>>>>> t6 int4 NULL,
>>>>>>>>>>> t7 int4 NULL,
>>>>>>>>>>> t8 int4 NULL,
>>>>>>>>>>> t9 int4 NULL,
>>>>>>>>>>> t10 int4 NULL,
>>>>>>>>>>> t11 int4 NULL,
>>>>>>>>>>> t12 int4 NULL,
>>>>>>>>>>> t13 int4 NULL,
>>>>>>>>>>> t14 int4 NULL,
>>>>>>>>>>> t15 int4 NULL,
>>>>>>>>>>> t16 int4 NULL,
>>>>>>>>>>> t17 int4 NULL,
>>>>>>>>>>> t18 int4 NULL,
>>>>>>>>>>> t19 int4 NULL,
>>>>>>>>>>> t20 int4 NULL,
>>>>>>>>>>> t21 int4 NULL,
>>>>>>>>>>> t22 int4 NULL,
>>>>>>>>>>> t23 int4 NULL,
>>>>>>>>>>> t24 int4 NULL,
>>>>>>>>>>> t25 int4 NULL,
>>>>>>>>>>> t26 int4 NULL,
>>>>>>>>>>> t27 int4 NULL,
>>>>>>>>>>> t28 int4 NULL,
>>>>>>>>>>> t29 int4 NULL,
>>>>>>>>>>> t30 int4 NULL,
>>>>>>>>>>> t31 int4 NULL,
>>>>>>>>>>> t32 int4 NULL,
>>>>>>>>>>> t33 int4 NULL,
>>>>>>>>>>> t34 int4 NULL,
>>>>>>>>>>> t35 int4 NULL,
>>>>>>>>>>> t36 int4 NULL,
>>>>>>>>>>> t37 int4 NULL,
>>>>>>>>>>> t38 int4 NULL,
>>>>>>>>>>> t39 int4 NULL,
>>>>>>>>>>> t40 int4 NULL,
>>>>>>>>>>> t41 int4 NULL,
>>>>>>>>>>> t42 int4 NULL,
>>>>>>>>>>> t43 int4 NULL,
>>>>>>>>>>> t44 int4 NULL,
>>>>>>>>>>> t45 int4 NULL,
>>>>>>>>>>> t46 int4 NULL,
>>>>>>>>>>> t47 int4 NULL,
>>>>>>>>>>> t48 int4 NULL,
>>>>>>>>>>> t49 int4 NULL,
>>>>>>>>>>> t50 int4 NULL,
>>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>>> );
>>>>>>>>>>>
>>>>>>>>>>> Every time when i query I will query it along with userid
>>>>>>>>>>> Ex : where userid = 12345678 and t1 in (1,2,3) and t2 in (0,1,2)
>>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>>
>>>>>>>>>>> On the other hand if I create a single jsonb column the schema
>>>>>>>>>>> will look like :
>>>>>>>>>>>
>>>>>>>>>>> CREATE TABLE dbo.googledocs_tbl (
>>>>>>>>>>> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1
>>>>>>>>>>> MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>>>>>>>>>>> userid int8 NOT NULL,
>>>>>>>>>>> addons_json jsonb default '{}'::jsonb
>>>>>>>>>>> CONSTRAINT googledocs_tbl_pkey PRIMARY KEY (gdid),
>>>>>>>>>>> );
>>>>>>>>>>>
>>>>>>>>>>> and the query would be like
>>>>>>>>>>> where userid = 12345678 and ((addons_json @> {t1:1}) or
>>>>>>>>>>> (addons_json @> {t1:2}) or (addons_json @> {t1:3})
>>>>>>>>>>> more key filters if customer applies
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 23, 2024 at 10:38 PM David G. Johnston <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 23, 2024, 10:01 Divyansh Gupta JNsThMAudy <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So here my question is considering one JSONB column is perfect
>>>>>>>>>>>>> or considering 50 columns will be more optimised.
>>>>>>>>>>>>>
>>>>>>>>>>>> The relational database engine is designed around the
>>>>>>>>>>>> column-based approach. Especially if the columns are generally unchanging,
>>>>>>>>>>>> combined with using fixed-width data types.
>>>>>>>>>>>>
>>>>>>>>>>>> David J.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Death to <Redacted>, and butter sauce.
>>>>>>>>> Don't boil me, I'm still alive.
>>>>>>>>> <Redacted> lobster!
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Death to <Redacted>, and butter sauce.
>>>>>>> Don't boil me, I'm still alive.
>>>>>>> <Redacted> lobster!
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Death to <Redacted>, and butter sauce.
>>>> Don't boil me, I'm still alive.
>>>> <Redacted> lobster!
>>>>
>>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 19:17 [email protected]
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: [email protected] @ 2024-12-23 19:17 UTC (permalink / raw)
To: [email protected]
Just out of curiosity, not suggestion this is the solution. Why save
json in PostgreSQL and not in a DB specialised on JSON like MongoDB?
Divyansh Gupta JNsThMAudy <[email protected]> escribió:
> Thank you everyone for giving your valuable responses, I am glad
> that everyone understands my concern. I got some good ideas about
> the database design that I am following after going through some
> stress testing I will implement the same.
>
> Thank you so much Everyone
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 21:03 David G. Johnston <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: David G. Johnston @ 2024-12-23 21:03 UTC (permalink / raw)
To: Divyansh Gupta JNsThMAudy <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
On Mon, Dec 23, 2024 at 11:26 AM Divyansh Gupta JNsThMAudy <
[email protected]> wrote:
>
> gdid int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1
> MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL,
>
> userid int8 NOT NULL,
>
> useremail varchar(600) NOT NULL,
>
> title public.citext NULL,
>
> authorname varchar(600) NULL,
>
> authoremail varchar(600) NULL,
>
> updated varchar(300) NOT NULL,
>
> entryid varchar(2000) NOT NULL,
>
> lastmodifiedby varchar(600) NULL,
>
> lastmodifiedbyemail varchar(600) NULL,
>
> "size" varchar(300) NULL,
>
> contenttype varchar(250) NULL,
>
> fileextension varchar(50) NULL,
>
> docfoldername public.citext NULL,
>
> folderresourceid public.citext NULL,
>
> filesize int8 DEFAULT 0 NOT NULL,
>
> retentionstatus int2 DEFAULT 0 NOT NULL,
>
> docfileref int8 NULL,
>
> usid int4 NULL,
>
> archivepath varchar(500) NULL,
>
> createddate timestamp(6) DEFAULT NULL::timestamp without time zone NULL,
>
> zipfilename varchar(100) NULL,
>
> oncreatedat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
>
> onupdateat timestamp(6) DEFAULT clock_timestamp() NOT NULL,
>
> startsnapshot int4 DEFAULT 0 NOT NULL,
>
> currentsnapshot int4 DEFAULT 0 NOT NULL,
>
> dismiss int2 DEFAULT 0 NOT NULL,
>
> checksum varchar NULL,
>
> typeoffile int2 GENERATED ALWAYS AS (
>
> CASE
>
> WHEN authoremail::text = useremail::text THEN 0::smallint
>
> ELSE 1::smallint
>
> END) STORED NOT NULL,
>
> parquetfilename varchar(100) NULL,
>
> metadata_vector tsvector GENERATED ALWAYS AS (to_tsvector('english'::
> regconfig, (((((COALESCE(title::character varying, ''::text::character
> varying)::text || ' '::text) || (COALESCE(docfoldername::text, ''::text)
> || ' '::text)) || (COALESCE(authorname, ''::text::character varying)::text
> || ' '::text)) || (COALESCE(fileextension, ''::text::character varying)::
> text || ' '::text)) || (COALESCE(lastmodifiedby, ''::text::character
> varying)::text || ' '::text)) || COALESCE(contenttype, ''::character
> varying::text::character varying)::text)) STORED NULL,
>
> isfileencrypted int4 DEFAULT 0 NULL,
>
> addons_json jsonb DEFAULT '{}'::jsonb NULL,
>
> CONSTRAINT googledocs_tbl_clone_pkey PRIMARY KEY (gdid, userid),
>
> CONSTRAINT fk_googledocs_tbl_clone_users_tbl FOREIGN KEY (userid)
> REFERENCES dbo.users_tbl(uid) ON DELETE CASCADE
>
> )
>
> PARTITION BY HASH (userid);
>
>>
>>>>
There are a lot of unconventional choices for data types and column naming
there...and it doesn't seem as normalized as it could be.
Besides that, consider that this probably should be at least two tables.
Put columns that you expect to change whenever the user makes a typical
edit on one table. Put those columns that can never change, or at least
would rarely do so, on another. Narrower tables is usually a win and with
this division you aren't throwing away and replacing all of the static data
each time the volatile data changes.
David J.
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Need help in database design
@ 2024-12-23 21:22 Greg Sabino Mullane <[email protected]>
parent: Divyansh Gupta JNsThMAudy <[email protected]>
1 sibling, 0 replies; 19+ messages in thread
From: Greg Sabino Mullane @ 2024-12-23 21:22 UTC (permalink / raw)
To: Divyansh Gupta JNsThMAudy <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
You might also look into using a bitmap, for some or all of those fields.
It depends on how many distinct values each can have, of course, and also
on how exactly they are accessed, but bitmaps can save you quite a bit of
space.
Cheers,
Greg
^ permalink raw reply [nested|flat] 19+ messages in thread
end of thread, other threads:[~2024-12-23 21:22 UTC | newest]
Thread overview: 19+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-12-23 17:29 Re: Need help in database design Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 17:31 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 17:39 ` Ron Johnson <[email protected]>
2024-12-23 17:49 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:08 ` Adrian Klaver <[email protected]>
2024-12-23 18:09 ` Ron Johnson <[email protected]>
2024-12-23 18:18 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:23 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:26 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:29 ` Ron Johnson <[email protected]>
2024-12-23 21:03 ` David G. Johnston <[email protected]>
2024-12-23 18:27 ` Ron Johnson <[email protected]>
2024-12-23 18:30 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:31 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 18:34 ` Arnold Morein <[email protected]>
2024-12-23 18:38 ` Ron Johnson <[email protected]>
2024-12-23 19:11 ` Divyansh Gupta JNsThMAudy <[email protected]>
2024-12-23 19:17 ` [email protected]
2024-12-23 21:22 ` Greg Sabino Mullane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox