我正在创建一个聊天应用程序，我会将所有对话和用户的聊天消息保存在一个分区（在 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
我现在明白生成序列是一个坏主意。所以剩下的是第二个选项，或者可能是一个序列建议，以防您争论它对查询性能的影响。