Re: Sequence Access Methods, round two

On Mon, Nov 10, 2025 at 04:31:07PM +0100, Andrei Lepikhov wrote:
> In multimaster, you may find an implementation of strictly monotone
> sequences. This method is covered by a GUC, impolitely named as 'Volkswagen
> method'.

I'm afraid that I cannot understand what you mean with this reference.

> However, it adds a massive overhead and is designed only for very
> narrow cases.

Are you referring to the function redirections required for the
callbacks here?  Or are you referring to something more specific?

> I skimmed your patches. It seems that 0003 and 0007 should be the first
> patches in the set.

Patch 0003 is named "Sequence access methods - backend support",
relying on two refactoring pieces.  Patch 0007 is the snowflake
contrib module, which is based on all the other patches.  So I don't
quite see what would be the point here based on how the patch is
currently written?

> Additionally, the approach itself appears overly complicated to me.
> Generally, I need a kinda of type parameter (like typmod) where I can
> propose the OID of the nextval routine and extra parameters - it may be
> serialised somewhere in pg_attribute.
> It seems even more flexible than a default_sequence_access_method, doesn't
> it?

Hmm.  How would this fit into a DDL model?  The advantage of the GUC
is to be able to hide from the client which sequence computation
method is used internally, with something like the following to forget
about the knowledge of the computation, so as it's fully transparent:
CREATE ACCESS METHOD popo
  TYPE SEQUENCE HANDLER popo_sequenceam_handler;
SET default_sequence_access_method = popo;
CREATE TABLE tab (a int GENERATED ALWAYS AS IDENTITY, b int);

It seems to me that you are proposing something slightly different,
then with an extra option, say a sort of "COMPUTATION" clause for
CREATE TABLE's sequence_options or CREATE SEQUENCE, where the name of
the function to use would be given to bypass nextval().  I don't
really get how this solves the transparency argument, because we'd
still need to update all the schemas to use something a different
function for the nextval(), no?  It would not deal with a bunch of
other states, like how we fetch sequence meta-data on upgrades, for
the new logical decoding feature where we may want a page LSN, and
setval().  lastval() remains the easy one as we just need to cache the
last 8-byte value, and we maintain the name of the sequence in a
static cache for each backend.

Anyway, there are also two more properties related to the in-core
sequences where the cases I have seen do not want to deal with:
- WAL generation, currently tracked by log_cnt, or be able to bypass
entirely WAL, or control the rate of the records.
- Storage, where no local storage is required for sequences.

It sounds like your case does really care much about these dealing
with these, where you would only need a shortcut to pass a nextval()
for a sequence, but I cannot say for sure if these two properties
matter for you, as well.
--
Michael