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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
