select (row_number() over ()), name from abc order by name;
row_number | name
------------+------
         1 | 1234
         2 | 1567
         3 | 2020
(3 rows)

Сохранить внутри красивой промежуточной таблицы и сунуть вместо содержимого старой.
Секвенцию отдельно исправить ( sequence, а не поле в таблице ).
Лучше потренироваться на кошках сначала.

Нескромный вопрос: зачем? Sequence используют для хранения порядка возникновения записей. Если вам этот попядок вообще не нужен, то зачем хранить его? Грохните столбец, оставьте дату и сортируйте по ней

Да лаба очередная, всяко.

Нафиг такие лабы, которые приучают думать подобными решениями.

rtfm ТРАНЗАКЦИЯ

Можно и то, и другое настраивать, кстати. ;)
Но если уже есть архив или есть возможность его сделать (+ещё сервер, то есть) — лучше streaming + restore_command, да.

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

> Нафиг такие лабы, которые приучают думать подобными решениями.

Я к тому, что нафиг такие представления, которые потом, к примеру, приводят к "решениям" по "синхронизации" данных в таблицах, завязанным на sequences. ;)

Если рассматривать в рамках базы, то да: значение, взятое позже, может банально быть закоммичено первым.
Если смотреть на весь условно-абстрактный сервис, использующий базу, то легко можно организовать такое, что генерируемые сервисом события в момент возникновения будут свои id в валидной последовательности получать, а время фактического коммита в базу при этом глубоко пофигу. Интересует только порядок появления события.
Да, в этом свои костыли горами  лежат неприкрыто, но используют же)

Ну и да, если смотреть в разрезе уникальных суррогатных ключей, то смысла ещё меньше

Это да, но тут уже нужно "организовывать".
И при этом обычно теряется основное свойство sequence — высокая производительность за счёт нетранзакционности.

Да

Ну человек зачем-то переделать их хочет согласно порядку записей при сортировке по столбцу дат. Значит порядок значений этой последовательности чем-то принципиален и что-то в него автором заложено. Возможно это и не работает даже правильно за пределами головы автора, но наличие смысла в порядке значений таки подразумевается.

Я вот и пытаюсь выяснить зачем оно, а другого варианта, кроме вышеописанного, я и сам даже за уши притянуть не могу)

Да, у автора задача совершенно "бесполезная", почти наверняка (как раз вызванная непониманием того, зачем нужны sequences и как они работают). ;)

Мне кажется что автор ещё совсем зелёный джун, которому дядя сениор сказал "отсортируй по году, и чтоб id начинался с 1". Давайте все будем лояльны к автору и укажем ему правильный путь, ну или нафиг его, пусть гуглит

Это зависит от очень многих факторов: от средней длины ключа, селективности префиксов, влезает ли индекс в память... Разница может быть от гомеопатической до гомерической.

Подскажите плиз как правильно записать данную команду
psql -U postgres -d broker -c 'DELETE FROM broker_user WHERE id='2';'

Записать куда?

в командную строку

так и вставляй XD