Re: Sequence Access Method WIP

On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote:
> - int64 minv, maxv, incby, bool is_cycled - these are basically options
> giving info about how the new numbers are allocated (I guess some
> implementations are not going to support all of those)
> - bool is_called - the current built-in sequence generator behaves
> differently based on it and I am not sure we can get over it (it could
> perhaps be done in back-end independently of AM?)

I think we might be able to get rid of is_called entirely. Or at least
get rid of it from the view of the AMs.

> Also makes me think that the seqam options interface should also be passed
> the minv/maxv/incby/is_cycled etc options for validation, not just the
> amoptions.

Sup.

BTW: Is 'is_cycled' a horrible name, or is that just me? Horribly easy
to confuse with the fact that a sequence has already wrapped around...

> >And it should return:
> >
> >int64 value - the first value allocated.
> >int nvalues - the number of values allocated.
> >am_private - updated private data.
> >
> 
> There is also more needed than this, you need:
> - int64 value - first value allocated (value to be returned)
> - int64 nvalues - number of values allocated
> - int64 last - last cached value (used for cached/last_value)
> - int64 next - last logged value (used for wal logging)
> - am_private - updated private data, must be possible to return as null

> I personally don't like that we need all the "nvalues", "next" and "last" as
> it makes the seqam a little bit too aware of the sequence logging internals
> in my opinion but I haven't found a way around it - it's impossible for
> backend to know how the AM will act around incby/maxv/minv/cycling so it
> can't really calculate these values by itself, unless ofcourse we fix the
> behavior and require seqams to behave predictably, but that somewhat breaks
> the whole idea of leaving the allocation to the seqam. Obviously it would
> also work to return list of allocated values and then backend could
> calculate the "value", "nvalues", "last", "next" from that list by itself,
> but I am worried about performance of that approach.

Yea, it's far from pretty.

I'm not convinced that the AM ever needs to/should care about
caching. To me that's more like a generic behaviour. So it probably
should be abstracted away from the individual AMs.

I think the allocation routine might also need to be able to indicate
whether WAL logging is needed or not.

One thing I want attention to be paid to is that the interface should be
able to support 'gapless' sequences. I.e. where nextval() (and thus
alloc) needs to wait until the last caller to it finished. That very
well can be relevant from the locking *and* WAL logging perspective.

Greetings,

Andres Freund

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