On Mon, Oct 15, 2012 at 2:33 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > Sequences, as defined by SQL Standard, provide a series of unique > values. The current implementation on PostgreSQL isolates the > generation mechanism to only a single node, as is common on many > RDBMS. > > For sharded or replicated systems it forces people to various hackish > mechanisms in user space for emulating a global or cluster-wide > sequence. > > The solution to this problem is an in-core solution that allows > coordination between nodes to guarantee unique values. > > There are a few options > 1) Manual separation of the value space, so that N1 has 50% of > possible values and N2 has 50%. That has problems when we reconfigure > the cluster, and requires complex manual reallocation of values. So it > starts good but ends badly. > 2) Automatic separation of the value space. This could mimic the > manual operation, so it does everything for you - but thats just > making a bad idea automatic > 3) Lazy allocation from the value space. When a node is close to > running out of values, it requests a new allocation and coordinates > with all nodes to confirm the new allocation is good.
While useful to some people, it seems like a way to avoid a crazy amount of complexity whereas most people are fine just using uncoordinated 128-bit integers. There are some who want temporal locality and smaller datums, but couldn't the problem be minimized somewhat by presuming non-coordinated identifier generation? It seems like a proper subset of what you propose, so perhaps that's a nice way to bisect the problem. I agree with you that an in-database way to do this -- even if in principle it could be done by clients most of the time -- would lend a lot more cohesion to the system. FWIW, I like "3" otherwise -- much like the foibles of most partitioning schemes and some of the stated design considerations of segment exclusion, I think absolute rigidity at all times makes it really hard to gradually move things into a desired alignment incrementally while the system is online. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
