В реляционной модели нет понятия порядка записей в таблице

Ребята привет. Проводим миграцию данных между БД с отличными структурами (с продакшена на тест допустим)
В таблицах используются id с автоинкрементом и есть куча связок по этим id

Планирую использовать схему
1. Для обнуления сиквенции
DROP test_table
Create test_table

2. И импортирую только те данные, которые нужны в test_table
INSERT INTO test_table (username, password, email) as
(SELECT username, password, email FROM prod_table)

Волнует вопрос сохранения связей ИД
1. Могу ли я импортировать ИД такой же как и в prod_table? добавив его в селект. Вдруг у нас есть удаленные записи и пропущенные id
2. Если первое невозможно и предположим, что удаленных записей нет - есть ли вероятность, что при загрузке перемешаются данные и не импортируются в том же порядке? Есть ли смысл добавить order by id в  селект?

Привет. А pg_repack запущенный на всю база без указания конкртных таблиц будет высвобождать ждисковое просттранство по мере обработки таблиц, или только когда завершит всю операцию для базы?  ИМеет ли смысл , поочередно указывать таблицы, в целях экономии меса на диске, или без разнцы, можно применять для все базы?

он работает потаблично. гнать его сразу по всей базе так себе идея. обычно выбираются таблицы, в которых известно наличие хотя бы 50% распухания. и по одной обрабатываются.
надо смотреть что он там жуёт за таблицу и посмотреть её текущий размер (включая индексы)
если распухания особо нет — он сделает полную копию со всеми индексами и потом подменит
ну и должно быть место под полную копию, да…

должен снести то, что не успел доделать: временную таблицу и индексы на ней

про londiste посмотрю, спасибо.

А в варианте со slony - нужно ли чтобы на обоих серверах slon был идентичной версии? или могут быть разные?

Походу, нужна идентичная: оно пытается загрузить свою либу $libdir/slony1_funcs.2.2.8 на всех хостах, и обламывается.
можно попробовать сделать симлинк ln -s slony1_funcs.2.2.7.so slony1_funcs.2.2.8.so, но что-то мне эта идея не нравится.

с постгисом это рекомендованный способ, но там надо в обратную сторону линковать - вместо более старой сошки можно временно осторожно положить более новую

Коллеги, подскажите!
Есть некая тяжелая вычислительная задача, связанная с активной работой с массивами.
Есть ее реализауия на pl/pgsql c неудовлетворительной производительностью - 10 секунд.
Есть реализация этой же задачи на C -  с отличной производительностью - 0.1 секунда, но по многим причинам решение на C использовать не получается. (В том числе и потому, что проект хостится на AWS RDB)
Вопрос: Что ожидать, если функцию переписать на PL/V8?
Есть ли шанс получить высокую производительность?