Re: Best practices for aggregate table design - Mailing list pgsql-general

From hari.fuchs@gmail.com
Subject Re: Best practices for aggregate table design
Date
Msg-id 87bnc9ol55.fsf@hf.protecting.net
Whole thread Raw
In response to Best practices for aggregate table design  (droberts <david.roberts@riverbed.com>)
Responses Re: Best practices for aggregate table design  (Vick Khera <vivek@khera.org>)
List pgsql-general
Thomas Kellerer <spam_eater@gmx.net> writes:

> droberts schrieb am 06.10.2015 um 20:53:
>> Okay, so is it safe to say I should use loosely use these guidelines when
>> deciding whether to model an attribute as a dimension
>> (type=[inbound,outbound]) vs. bundling with a measure (total_inbound) ?
>>
>> If you know the number of values for a dimension are fixed (e.g. boolean),
>> then creating a measure will have benefits of:
>>   - reduced number of rows/storage
>>   - better performance since less indexing/vacuuming
>>
>> the drawbacks are:
>>   -rigid structure, not very extensible over time (e.g. later realize I need
>> to also track 'internal' calls).
>>
>> In my case, I'm now needing to add another measure 'encrypted=true/false',
>> so my table is starting to look like
>
> Have you considered using a hstore column to store the attributes you
> don't know yet?
>
> Which makes this extensible, flexible and fast.

Is there an advantage of hstore vs. json/jsonb?

pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: Best practices for aggregate table design
Next
From: Oleksii Kliukin
Date:
Subject: Re: dubious optimization of the function in SELECT INTO target list