Re: Sequence Access Methods, round two - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Sequence Access Methods, round two
Date
Msg-id aQ56fs72fxKqV3so@paquier.xyz
Whole thread Raw
In response to Re: Sequence Access Methods, round two  (Andrei Lepikhov <lepihov@gmail.com>)
List pgsql-hackers
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.

> 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.

> 3. I wonder if postgres_fdw-based shardman could benefit from that. I
> imagine an implementation of an auto-partitioned table where the
> partitioning key is generated automatically based on the partition where the
> tuple is inserted.

Yeah, I don't see why this would not work.

> 4. Any kind of non-uniform distribution may be implemented that is helpful
> for testing purposes

This one is perhaps nice to have but it's low priority compared to the
others and the possibility to hide the computation behind native DDLs
that use sequences underground (SERIAL and GENERATED).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Extended Statistics set/restore/clear functions.
Next
From: Michael Paquier
Date:
Subject: Re: Improve read_local_xlog_page_guts by replacing polling with latch-based waiting