Re: UUIDs & Clustered Indexes - Mailing list pgsql-general

From Mike Sofen
Subject Re: UUIDs & Clustered Indexes
Date
Msg-id 033201d20338$77a687a0$66f396e0$@runbox.com
Whole thread Raw
In response to Re: UUIDs & Clustered Indexes  (George Neuner <gneuner2@comcast.net>)
List pgsql-general

From: George Neuner  Sent: Tuesday, August 30, 2016 5:54 PM

>Mike Sofen wrote: So in this scenario, I'm using

>BOTH bigserials as the PK and uuids as AKs in the core tables.  I

>reference the bigints for all joins and (have to) use the uuids for the

>filters.  It's been working ok so far, lookup performance on a table

>with a few million rows, using the uuid (indexed) is instantaneous. 

>I'll soon have a 100 million+ rows loaded into a single table and know a bit more.

>The uuids are also design insurance for me in case I need to shard,

>since I'll need/want that uniqueness across servers.

 

FYI:  articles about sharding using bigint keys.

 

http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

http://rob.conery.io/2014/05/29/a-better-id-generator-for-postgresql/

 

George

 

I remember reading these articles a long time ago, forgot about them...and appreciate the reminder! 

 

I really liked the enhanced Instagram function from Rob Conery in the second link, but so far haven’t needed to deal with it.  However, an upcoming project may require huge data storage – approaching hundreds of billions of rows, and I’m sticking with Postgres – so this will be a great way to test drive the function.  And I may try my hand at a further enhancement, time permitting.  Thanks for the links!

 

Mike

 

pgsql-general by date:

Previous
From: George Neuner
Date:
Subject: Re: UUIDs & Clustered Indexes
Next
From: "Karl O. Pinc"
Date:
Subject: postgresql.conf RH comment, and a systemd RH note