我正在创建一个聊天应用程序，我会将所有对话和用户的聊天消息保存在一个分区（在 convo ids 上）的 BRIN 索引表中。当我的服务器想要存储新消息时，它必须知道每个对话的最后一条消息的序列号。可能会有很多对话，那么为数据库中的每个对话动态生成一个序列（CREATE SEQUENCE 序列）可以吗？
我将使用带有 Nodejs 网络服务器集群和 REDIS 实例的数据库。从语义上讲，redis 位于 nodejs 和 Postgres db 之间。我的第二个想法是代替序列，我将创建一个表来保存每个 convo（两列）的计数器，将计数器加载到 redis 中，并在聊天时锁定行，在那里递增并定期写回。
哪个更好，这些都好吗？谢谢！
编辑
消息表是基于 convo id 和消息号索引的多列 BRIN。并且两列没有pk，也没有唯一约束。可能存在差距，甚至可能存在重复（由于 redis INCR 的原子性，这不太可能，因为它将是唯一的实例）（另一个重要点）
我必须详细说明。我收到两个回复，告诉我只需为数据库中的每条消息制作一个序列。问题在于布林指数的长期有效性。这就是我在问题中写它的原因，因为它很重要。如果你不知道 brin 指数是如何工作的，请查一下。本质上它是一个范围索引。现在，如果您对所有消息进行一个序列，您会看到会发生什么。对于 brin，消息编号/id 不会添加任何信息，因为随着时间的推移，所有对话的所有消息 id 将介于一个相对较小的数字和最后一个序列值之间。我认为那会大大降低选择速度。这是聊天应用程序。我将不得不在登录时查询未发送的消息。并且不要告诉我使用 btree 甚至不要回答谢谢：D
我曾考虑过 UUID，但出于与上述相同的原因，这不会有帮助。
编辑 2
我现在明白生成序列是一个坏主意。所以剩下的是第二个选项，或者可能是一个序列建议，以防您争论它对查询性能的影响。
我的经验主要是在甲骨文。但从数据库的角度来看，获取序列就像 Java 单例。一个进程一次可以得到一个序列。您需要生成的序列越多，生成序列的节点越多，插入的延迟就越高。你可以看看使用uuids。自然键是最好的。就像 user_id 和时间戳一样。但是在集群中的多个节点上使用序列可能不会像您希望的那样工作。
TL;博士
每次对话的顺序
众所周知，DDL 语句很昂贵。此外，它通常需要对数据字典进行序列化。您不能同时创建多个序列。
这种方法是一个“坏主意”。
表中的值
为防止重复 ID，您需要对该表进行锁定。这是一个已知的序列化点。（我已经在这里写过一些关于这个方法的东西）
这种方法也是一个“坏主意”。
单序列
序列旨在以高消耗率有效地产生唯一的 ID 值。可以跨多个会话并行获取这些值。
其他方法需要序列化。序列化对数据库不利。
反而：