On 17 October 2012 10:19, Markus Wanner <mar...@bluegap.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
