From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: "Shared strings"-style table |
Date: | 2017-10-13 19:03:10 |
Message-ID: | orr2l8$m5t$1@blaine.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Seamus Abshere schrieb am 13.10.2017 um 18:43:
>>> On Fri, Oct 13, 2017 at 8:49 AM, Seamus Abshere wrote:
>>>> Theoretically / blue sky, could there be a table or column type that
>>>> transparently handles "shared strings" like this, reducing size on disk
>>>> at the cost of lookup overhead for all queries?
>>>> (I guess maybe it's like TOAST, but content-hashed and de-duped and not
>>>> only for large objects?)
>
> On Fri, Oct 13, 2017, at 01:29 PM, Melvin Davidson wrote:
>> What was described is exactly what relations and Foreign Keys are for.
>
> hi Melvin, appreciate the reminder. Our issue is that we have 300+
> columns and frequently include them in the SELECT or WHERE clauses... so
> traditional normalization would involve hundreds of joins.
>
> That's why I ask about a new table or column type that handles basic
> translation and de-duping transparently, keeping the coded values
> in-table.
As those are all strings: why not put them into a hstore (or jsonb) column?
Then all of them could compressed (TOASTed) as a single value instead of 300 independent values.
From | Date | Subject | |
---|---|---|---|
Next Message | Seamus Abshere | 2017-10-13 19:08:57 | Re: "Shared strings"-style table |
Previous Message | David G. Johnston | 2017-10-13 18:21:22 | Re: Permissions for Web App |