On 16/09/14 14:17, Andres Freund wrote:
> On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote:
>>
>> 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.
Well that means we probably want to return first allocated value, last
allocated value and then some boolean that tells backend if to wal log
the sequence or not (number of values allocated does not really seem to
be important unless I am missing something).
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services