Re: Composite type storage overhead

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Laiszner Tamás <t(dot)laiszner(at)outlook(dot)com>
Cc: Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Composite type storage overhead
Date: 2019-10-25 18:57:57
Message-ID: CAHOFxGqhV-womDiquSgVYw5o8WEsGU1UcfYbT4wUViMfbJ_--Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Oct 24, 2019 at 3:35 AM Laiszner Tamás <t(dot)laiszner(at)outlook(dot)com>
wrote:

> Actually, this is not such a unique idea:
> https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c
>
> Thanks for the suggestion to split up the primary key into components. But
> even going down this way, packing the components into one superstructure
> (composite type) would be beneficial as the same scheme is used across
> multiple tables. And we are back at the original problem.
>

This is probably a completely naive question, but why not store this in a
text field?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Farber 2019-10-25 20:19:55 Re: Trying to fetch records only if preceded by at least another one
Previous Message Tom Lane 2019-10-25 17:33:38 Re: Quere keep using temporary files