Re: Global Sequences - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Global Sequences
Date
Msg-id CAAZKuFaxHK9xDZNio4y+Rc0eyoa5ywY=tPFnvM34KXW6Sg0B8A@mail.gmail.com
Whole thread Raw
In response to Global Sequences  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Oct 15, 2012 at 2: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.
>
> 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



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: [WIP] pg_ping utility
Next
From: Bruce Momjian
Date:
Subject: Re: Deprecating RULES