Hacker News Reader

Comment by skyde | Hacker News Reader

Curious why your primary key are GUID? Also if the primary key of table C is made of 3 column (A GUID, B GUID, C GUID) the index in PostgreSQL will not be that big with compression enabled because all the common prefix will not be stored redundantly.

Also having a single compound index on table C covering column (A ForeingKey, B ForeingKey, C GUID) is much better than having multiple index on table C.

View on HN

Having the primary key generatable at application level has performance benefits especially on inserts. You can write all related entities in one go vs waiting for db to generate the the pk, and passing that to dependent entities.

you can have "id" Generatable at application level without using GUID. This is what twitter is doing "snowflake".

It generate tens of thousands of ids per second. Those id fit in 64 bits. And those id are sortable, meaning that if tweets A and B are posted around the same time, they should have ids in close proximity to one another.

See: https://blog.twitter.com/engineering/en_us/a/2010/announcing...

Also the problem with clustered indexes in a GUID field are that the GUIDs are random, so when a new record is inserted, a significant portion of the data on disk has to be moved to insert the records into the middle of the table.

GUIDs are extremely useful if you want to move and merge data around without having to worry about primary key collisions.

Reply on news.ycombinator.com