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
