Re: Global Sequences

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Global Sequences
Date: 2012-10-17 08:34:12
Message-ID: CA+U5nM+kE0bds+WSyXxKLh0U3JojsQ2cEepMv7P9i+yCz=2moA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 October 2012 09:10, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> Simon,
>
> On 10/16/2012 02:36 PM, Simon Riggs wrote:
>> Where else would you put the hook? The hook's location as described
>> won't change whether you decide you want 1, 2 or 3.
>
> You assume we want an API that supports all three options. In that case,
> yes, the hooks need to be very general.

I'm not assuming that, so much of what you say is moot, though it is
good and welcome input.

> Given that option 3 got by far the most support, I question whether we
> need such a highly general API. I envision an API that keeps the
> bookkeeping and cache lookup functionality within Postgres. So we have a
> single, combined-effort, known working implementation for that.

IMHO an API is required for "give me the next allocation of numbers",
essentially a bulk equivalent of nextval().

Anything lower level is going to depend upon implementation details
that I don't think we should expose.

I'm sure there will be much commonality between 2 similar
implementations, just as there is similar code in each index type. But
maintaining modularity is important and ahead of us actually seeing 2
implementations, trying to prejudge that is going to slow us all down
and likely screw us up.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2012-10-17 09:19:12 Re: Global Sequences
Previous Message Markus Wanner 2012-10-17 08:20:58 Re: Global Sequences