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

From Thomas Kellerer
Subject Re: Best practices for aggregate table design
Date
Msg-id mv50j3$1a8$1@ger.gmane.org
Whole thread Raw
In response to Re: Best practices for aggregate table design  (droberts <david.roberts@riverbed.com>)
Responses Re: Best practices for aggregate table design
List pgsql-general
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.



pgsql-general by date:

Previous
From: "Ramalingam, Sankarakumar"
Date:
Subject: Re: postgres standby won't start
Next
From: hari.fuchs@gmail.com
Date:
Subject: Re: Best practices for aggregate table design