From: | Jason Dusek <jason(dot)dusek(at)gmail(dot)com> |
---|---|
To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Guyren Howe <guyren(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Uber migrated from Postgres to MySQL |
Date: | 2016-07-31 02:47:17 |
Message-ID: | CAO3NbwPRcN1_5Y+8Q4UfmJEvXpEJizTiJ+BLdX2go6MbVBmK2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 28 Jul 2016 at 01:18 Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
wrote:
> On 28/07/16 17:52, Jason Dusek wrote:
> > With regards to write amplification, it makes me think about about
> > OIDs. Used to be, every row had an OID and that OID persisted across
> > row versions.
> >
> >
> https://www.postgresql.org/docs/9.5/static/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS
> >
> > Would reintroducing such a feature address some of Uber's concerns
> > about multiple indexes? It could, and would do so without the implicit
> > requirement of a foreign key; but it would also require a fast OID to
> > CTID mapping.
>
> Would it be best to increase OIDs to 64 bits?
>
> Possibly a choice of 32/64 to be decided when the DB is created???
>
Moving to 64 bit OIDs would make the OID->CTID mapping take more memory and
could, consequently, make it slower; but OIDs would seem to be required to
support temporal tables so maybe they should make a comeback?
Kind Regards,
Jason Dusek
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-07-31 14:59:49 | Re: pg_dumping extensions having sequences with 9.6beta3 |
Previous Message | Silk Parrot | 2016-07-31 02:07:09 | How to best archetect Multi-Tenant SaaS application using Postgres |