Да, точно Вам хотел ответить.
Да при том, что ни такие генераторы, ни текущее время в обычной ситуации порядку вставки (и вообще изменения) данных в БД не соответствуют.
Мне любопытно, чем уникальна ситуация — Вы же написали, что в ней порядок добавления чему-то такому соответствует, так?

Причём тут now()?

Есть ещё вариант, но он, однако, не масштабируем, а приложение должно поддерживать средства синхронизации (т.е. php не годится). В каком-то столбце храним bigint и при каждом запросе при вставке записи туда пишем число, защищённое мьютексом. После записи увеличиваем его на 1. При старте приложения нужно из базы читать максимальное значение. Тогда чётко будет регламентирован порядок, но, опять-таки это не масштабируемо.

Вот при этом: https://t.me/pgsql/277323
И вот этом: https://t.me/pgsql/277307
И этом: https://t.me/pgsql/277299

Т.е. Вы, похоже, думаете, что реальное время связано с порядком добавления.
Если это в Вашем случае так, мне интересно, почему.

Сервис хранения информации получает по rpc данные. В ответ отдаётся id. Далее данные трансформируются, часть уходит в postgresql, вторая часть в другое место. В postgresql нужно будет сортировать данные в порядке получения id (в порядке создания, сохранения), получать строки до и после id. Что не так? Причём тут now? Мой вопрос про хранение и сортировку информации. Кто-нибудь имел опыт с такими id в postgresql? Возможно, какие-нибудь минусы всплыли

Здравствуйте , можете помочь с db для соц сети ? Для хранения информации решил использовать дерево itree грубо говоря  user  
User.friends user.dialogs user.info

Или лучше как то по другому это организовать?

С какими “такими”? Вы имеете в виду какую-то конкретную “такую” реализацию или мы сейчас думаем о том, как “такое” реализовать?

Походу, мне тоже нужно что-то употребить. https://t.me/pgsql/277296

> Сервис хранения информации получает по rpc данные. В ответ отдаётся id.

Так, а при чём тут тогда были генераторы?

> В postgresql нужно будет сортировать данные в порядке получения id

Тогда порядок "создания, сохранения" не имеет никакого отношения к делу, нет?
Т.е. Вам просто нужны сортируемые id, которые Вы будете сохранять и использовать, вот и всё.

> Причём тут now?

Ни при чём, казалось бы. Как и порядок появления данных в базе. Т.е. делаете сортируемые id и верите им, и всё, разве нет?

> Кто-нибудь имел опыт с такими id в postgresql? Возможно, какие-нибудь минусы всплыли

И всё равно непонятно, какие тут могут быть минусы. Хоть из PostgreSQL-овской sequence или её аналога выдаёте эти id, да и всё.

Да сделайте композитный тип с временем, номером ноды и значением локального сиквенса.

А как это будет связано с сортировкой? В общем, задачу я так и не понял. :(

Да не нужна там строгая сортировка соответствующая порядку транзакций, которая, как вы правильно сказали, мнимая. Нужна уникальность для всех шард и возможность упорядочить по примерному времени добавления.

Не хочется в разных колонках, можно в одной, через композитный тип

over-engineering detected?

С точки зрения клиента - rpc сервис и есть база

Boltun 80lvl detected. Возможно, он просто хочет поговорить и поэтому пытается увести разговор в другую сторону

а я про ваш подход. нужна возможность сортировать ID — берите bigint. понадобиться сортировать по времени — добавите timestamptz.
если это всё будет плохо работать на адекватном железе — наймёте спецов, уже должна быть возможность

Соцопрос: какое значение idle_in_transaction_session_timeout обычно держите и есть ли любители посидеть с DBeaver / any GUI с выкл автокоммитом?

сейчас 30min, но это же от нагрузки и приложений зависит