On Mon, Oct 15, 2012 at 5:33 PM, Simon Riggs <simon@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.
I remember constructing at least the thought process surrounding your
"option #3" as the one thing thing I arrived at that seemed as though
it might be valuable for the many-years-ago Slony-II summit.
The notion of having each node give out sections of a sequence seems
pretty viable; as a hugely loose analogy, DHCP servers take a
somewhat similar approach in assigning IP addresses in ranges shared
across those servers.
At the time, back in, I think, 2005, there was some agreement that it
was a viable idea to give out chunks of sequence range; it wasn't one
of the tough problems warranting Heavy Thought, so there wasn't any
concentration on it, and that pretty all went by the wayside.
Today, I am somewhat skeptical that there's much value to the
exercise. It isn't difficult to come up with pretty unique values,
between constructing something with a node ID prefix or such, or using
a DCE UUID that is very likely to be globally unique.
The reason to want a "global sequence" is that it's supposed to give
out values in pretty much a sequential order. But a "shared global
sequence" will have aspects of that that are decidedly *not* in
sequential order. If it's partially *un*ordered, I suspect this
undermines the value of it.
There's a necessary trade-off; you can either have it globally
*strongly* ordered, and, if so, you'll have to pay a hefty
coordination price, or you can have the cheaper answer of a weakly
ordered sequence. The latter leaves me feeling rather "meh."
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
