Re: Sequence Access Methods, round two

On Sun, May 17, 2026 at 08:03:15AM +0200, Andrei Lepikhov wrote:
> Right now, awaiting this feature, I use a nextval hook. But it is just to
> minimise the number of core lines that need to be changed. Neither hook nor
> callback is a good idea here - sequence source might be only one for a specific
> table; \d should show an unequivocal definition of a table.
> Also, the AM machinery makes the dump/restore use cases clear. Logical
> replication plugins also benefit from it: pgactive, pglogical, and spock all
> include Auto-DDL solutions that simplify the management of sequence generation
> methods across instances.

There was zero feedback from other core developers, so it's really
hard to weigh about its acceptance. My guess is that nobody really
cares about this thread, which is just the way it is on -hackers for
some things. FWIW, I still like what I've done in this patch and this
design.

> Initially, I thought there was no reason to benchmark performance here: a couple
> of function calls compared to accessing the sequence table shouldn't affect
> performance. But looking into RelationInitSequenceAccessMethod more closely, I
> found it could be improved.
> It should have a fast path for local sequences: rd_amhandler and relam might
> avoid cache lookup and be wired into constants, like
> F_SEQ_LOCAL_SEQUENCEAM_HANDLER and HEAP_TABLE_AM_OID. So, maybe benchmarking
> might find some extra optimisations.

Testing the worst case scenario we can think of and making sure that
it deals no regression is a common thing to do anyway for code paths
that can be heavily involved in query execution, be the queries
analytical or OLTP.
--
Michael