Re: Sequence Access Methods, round two
| От | Michael Paquier |
|---|---|
| Тема | Re: Sequence Access Methods, round two |
| Дата | |
| Msg-id | aQ56fs72fxKqV3so@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Sequence Access Methods, round two (Andrei Lepikhov <lepihov@gmail.com>) |
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: