Re: Sequence Access Methods, round two

On 17/05/2026 01:09, Michael Paquier wrote:
> On Fri, May 15, 2026 at 11:04:37AM +0200, Andrei Lepikhov wrote:
>> Here is a rebased version of the patch set.
>> It is generally looks quite elegant. Of course, an int64 value seems a little
>> restrictive, but in practice, with four different algorithms on board, I don't
>> need a value larger than 64 bits at this moment.
>
> Neither do I. Note that I have dropped this patch set from the commit
> fest as I was/still-am not sure about its future, and there is a lack
> of enthusiasm around it.

What's the source of the hesitation? In my mind, if custom sequences are needed,
this approach is an essential solution.
As I see it, distributed applications want it. Recent efforts in logical
replication (conflict logging, sequence syncing) show that some parts of the
community are adopting Postgres for multi-instance configurations.

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.

>> 3. Sleep call under the lock. It might not be so inevitable, and call it only
>> when the time value stays the same.
>
> That's the last patch of the series. This can be tweaked infinitely
> with the right API infrastructure in place.

Agree, just noted.

>
> One thing that I have been pondering about is a worst-case scenario
> with a benchmark that could show a performance impact due to the
> function pointers:

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.

--
regards, Andrei Lepikhov,
pgEdge