Is COMB GUID a good idea with Rails 3.1 if I use GUIDs for primary keys?

Question

I\'m using Rails 3.1 with PostgreSQL 8.4. Let\'s assume I want/need to use GUID primary keys. One potential drawback is index fragmentation. In MS SQL, a recommended solutio

Answer 1

• Does PostgreSQL suffer from index fragmentation when the PRIMARY KEY is type UUID?

Yes, it's to be expected. But if you're going to use the COMB strategy that won't happen. The rows will be always in order(that's not entirely true, but bear with me).

Also, the performance between native pgsql UUID vs VARCHAR is not all that different. Another point to consider.

• Is fragmentation avoided if the low-order 6 bytes of the GUID are sequential?

In my test I've found that UUID1(RFC 4122) is sequential, there's already a timestamp added in the generated uuid. But yes, adding a timestamp in the last 6 bytes will reassure that ordering. That's what I did anyway, because apparently the timestamp already present is not guarantee of order. More about COMB here

• Is the COMB GUID as implemented below an acceptable, reliable way to create sequential GUIDs in Rails?

I'm not using rails, but I'll show you how I did it in django:

import uuid, time

def uuid1_comb(obj):
    return uuid.uuid1(node=int(time.time() * 1000))

Where node is a 48-bit positive integer identifying the hardware address.

About your implementation, one of the main advantages of using uuid's is that you can safely generate them outside the database, so, using a helper class is one valid way to do it. You can always use an external service for uuid generation like snowflake, but it may be premature optimizacion at this point.