Re: Indirect indexes - Mailing list pgsql-hackers

From Adam Brusselback
Subject Re: Indirect indexes
Date
Msg-id CAMjNa7fk7gFKtJ7s0AJ2dk+H=dfbt1bTLc9kNimf8ikzObGpWg@mail.gmail.com
Whole thread Raw
In response to Re: Indirect indexes  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Indirect indexes  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Just throwing an anecdote out there, but my company uses UUID for primary keys on every table in the DB.  While int4 is for sure more popular, it would be nice if there weren't even more reasons to "force" people in that direction.  I know I started regretting the decision to go with UUID primary keys slightly once I realized that we'd need exclusion constraints, and you have to jump through hoops to use them together.

My main point is that maybe the reason why most users use int4 pkeys (besides conventional wisdom) is because it gets the most support from features like this, and it may not be quite as skewed if that same support were given to other types.

Just my $0.02
-Adam

On Fri, Oct 21, 2016 at 4:46 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 10/19/16 7:52 AM, Robert Haas wrote:
So, I think that this is a really promising direction, but also that
you should try very hard to try to get out from under this 6-byte PK
limitation.  That seems really ugly, and in practice it probably means
your PK is probably going to be limited to int4, which is kind of sad
since it leaves people using int8 or text PKs out in the cold.

My impression is that int4 is by far the most popular PK type. Even if the initial implementation is limited to that I think it'd have a lot of potential.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: emergency outage requiring database restart
Next
From: Jim Nasby
Date:
Subject: Re: Improve output of BitmapAnd EXPLAIN ANALYZE