Re: Sequence Access Methods, round two

On 8/11/2025 00:02, Michael Paquier wrote:
> On Fri, Nov 07, 2025 at 05:05:55PM +0100, Andrei Lepikhov wrote:
>> 1. For pgEdge Snowflake, it would be really beneficial - there are not only
>> code copying issues, but also the Serial -> Snowflake conversion algorithm.
>> Additionally, for now, only an in-core sequence can be used as an 'identity
>> always' column.
>
> Perhaps pgedge is bypassing that by telling users to enforce a
> sequence rule with a function attached to an attribute default?
> Schema modifications usually feel meh for any users.
>
Like that.

>> 2. Multimaster project [1] also attempts to resolve the sequence issue. You
>> may check how its developers tackle the problem - I guess any active-active
>> configuration needs it.
>
> I've wanted that for 15 years or so with for strictly-monotone values
> shared across nodes, so there's that. Remember Postgres-XC.
>
In multimaster, you may find an implementation of strictly monotone
sequences. This method is covered by a GUC, impolitely named as
'Volkswagen method'. However, it adds a massive overhead and is designed
only for very narrow cases.

I skimmed your patches. It seems that 0003 and 0007 should be the first
patches in the set.
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?

--
regards, Andrei Lepikhov,
pgEdge