Re: Sequence Access Method WIP

On 2013-11-18 12:50:21 +0200, Heikki Linnakangas wrote:
> On 18.11.2013 11:48, Andres Freund wrote:
> I don't think the sequence AM should be in control of 'cached'. The caching
> is done outside the AM. And log_cnt probably should be passed to the _alloc
> function directly as an argument, ie. the server code asks the AM to
> allocate N new values in one call.

Sounds sane.

> I'm thinking that the alloc function should look something like this:
>
> seqam_alloc(Relation seqrel, int nrequested, Datum am_private)

I don't think we can avoid giving access to the other columns of
pg_sequence, stuff like increment, limits et all need to be available
for reading, so that'd also need to get passed in. And we need to signal
that am_private can be NULL, otherwise we'd end up with ugly ways to
signal that.
So I'd say to pass in the entire tuple, and return a copy? Alternatively
we can return am_private as a 'struct varlena *', so we can properly
signal empty values.

We also need a way to set am_private from outside
seqam_alloc/setval/... Many of the fancier sequences that people talked
about will need preallocation somewhere in the background. As proposed
that's easy enough to write using log_sequence_tuple(), this way we'd
need something that calls a callback with the appropriate buffer lock
held. So maybe a seqam_update(Relation seqrel, ...) callback that get's
called when somebody executes pg_sequence_update(oid)?

It'd probably a good idea to provide a generic function for checking
whether a new value falls in the boundaries of the sequence's min, max +
error handling.

> I'm not thinking that we'd change sequences to not be relations. I'm
> thinking that we might not want to store the state as a one-page file
> anymore. In fact that was just discussed in the other thread titled
> "init_sequence spill to hash table".

Yes, I read and even commented in that thread... But nothing in the
current proposed API would prevent you from going in that direction,
you'd just get passed in a different tuple/buffer.

> >b) It's not actually easy to get similar semantics in "userspace". How
> >would you emulate the crash-safe but non-transactional semantics of
> >sequences without copying most of sequence.c? Without writing
> >XLogInsert()s which we cannot do from a out-of-tree code?
>
> heap_inplace_update()

That gets the crashsafe part partially (doesn't allow making the tuple
wider than before), but not the caching/stateful part et al. The point
is that you need most of sequence.c again.

Greetings,

Andres Freund

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