Re: Global Sequences

On 17 October 2012 10:19, Markus Wanner <markus(at)bluegap(dot)ch> wrote:

> On 10/17/2012 10:34 AM, Simon Riggs wrote:
>> IMHO an API is required for "give me the next allocation of numbers",
>> essentially a bulk equivalent of nextval().
>
> Agreed. That pretty exactly matches what I described (and what's
> implemented in Postgres-R). The API then only needs to be called every N
> invocations of nextval(), because otherwise nextval() can simply return
> a cached number previously allocated in a single step, eliminating a lot
> of the communication overhead.
>
> You realize an API at that level doesn't allow for an implementation of
> options 1 and 2? (Which I'm convinced we don't need, so that's fine with
> me).
>
>> Anything lower level is going to depend upon implementation details
>> that I don't think we should expose.
>
> Exactly. Just like we shouldn't expose other implementation details,
> like writing to system catalogs or WAL.
>
>> 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.
>
> Agreed. Let me add, that modularity only serves a purpose, if the
> boundaries between the modules are chosen wisely. It sounds like we are
> on the same page, though.
>
> To testify this: IMHO an API for setval() is required to invalidate all
> node's caches and re-set an initial value, as a starting point for the
> next bulk of numbers that nextval() will return.
>
> currval() doesn't need to be changed or "hooked" at all, because it's a
> read-only operation.

Agreed....

API calls for sam_nextval_alloc() and sam_setval()
using Tom's Sequence Access Method naming.

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