Сергей Соловьев

А в чем проблема? Он говорит, что у каждой джобы есть свой идентификатор. Разные джобы (с разными ID) могут запускаться параллельно, но если этот ID одинаковый, то становятся в очередь и запускаются последовательно.
Т.е. пункт а выполняется (хотя могут и быть другие уточнения)

Используй LEFT JOIN с группировкой и having фильтром. Примерно так:

select m.id, min(s.sent_at) min_sent_time from message m 
      left join sent_log s on m.id = s.message_id
group by m.id
having min(s.sent_at) is null or min(s.sent_at) < :time;

Вместо :time подставь свое значение

Не знаю бизнес-логику, но первый и второй запросы должны дать разные результаты - не факт, что у тебя ID будет указывать на точное расположение записи в этой таблице, т.е. LIMIT 100 OFFSET 95500 и WHERE id BETWEEN 95500 AND 95600 - это разные вещи.

И еще - большая часть ресурсов уходит на то, чтобы вызвать jsonb_array_contents. ProjectSet узел дает больший вес. Скорее всего, это потому что там находится 95600 элементов в массиве.

Скорее всего, ты хочешь реализовать пагинацию. В PostgreSQL для этого существуют курсоры:

DECLARE array_elements CURSOR FOR
select
  jsonb_array_elements(content->'blocks') as content
from
  data
where
  "order" = 2 and external_id = 1;

А потом используешь его:

FETCH 100 FROM array_elements;

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

CREATE TABLE array_elements(
   order integer REFERENCES data("order"),
   external_id integer REFERENCES data(external_id),
   element jsonb
);
CREATE INDEX array_elements_order_external_id_idx on array_elements(order, external_id);

Использовать курсор при этом не запрещается.

Нельзя это сделать.
Причин много:
1. Все данные хранятся не в 1 файле, а в нескольких
2. В файлах хранятся не вот уже готовые данные, а множество различных кортежей - для MVCC. А без понимания ID транзакции (которая в другой БД будет иной) они бессмысленны. То есть, переложив физически файлы ты получишь белеберду
3. В Postgres нет возможности приаттачить файлы. Есть возможность INSERT/COPY, сдампить, но файлы напрямую нельзя. (нет такой опции в Attach)
4. В файле хранятся не сериализованные в независимом формате данные, а (грубо говоря) структуры C. Как они располагаются зависит от endianess, компилятора и т.д.
5. Даже если ты это все сделаешь, то не факт, что различные OID сойдутся - т.е. таблица будет хранить OID, которого в другой БД не существует

Если хочешь ускорить процесс, но используй pg_dump с ключом -fd (специальный формат), а в pg_restore -j NJOBS - распараллеливание (NJOBS - кол-во воркеров).

Попробуй GIST индекс

SELECT distinct 
      LAST_VALUE(id) OVER (PARTITION BY created_at::date ORDER BY value DESC RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) id, 
      LAST_VALUE(value) OVER (PARTITION BY created_at::date ORDER BY value DESC RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) value, 
      LAST_VALUE(created_at) OVER (PARTITION BY created_at::date ORDER BY value DESC RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) created_at 
FROM tbl 
ORDER BY created_at;

Как уже сказали: .pgpass (предпочтительный) или через флаг -W

Также можно задать переменную окружения PGPASSWORD (но также не безопасно, т.к. виден в ps)

PGPASSWORD=password psql -h 192.168.20.145 -p 5432 -U tony -d trn -с "Some magic things"

P.S. если это в скрипте, то лучше будет самому скрипту передать переменную

PGPASSWORD=password ./connect-psql.sh

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


Если мы говорим про postgres, то если ты обновил какую-то запись (кортеж), то неявно получаешь на нее (запись) блокировку. Когда кто-то другой хочет обновить эту же запись, то ждет ее освобождения.
В данном случае (визуализация), 1 процесс выполнял UPDATE X, Y а другой UPDATE Y, X, т.е. первый взял блокировку сначала на X потом на Y, а другой - сначала на Y потом на X. Первая блокировка успешна, но вторые нет - они уже заняты.
В данном случае, разрешить их нельзя, т.к. оба ждут пока один из них снимет блокировку, но этого не произойдет. Блокировка со строки снимется по окончании транзакции.

Совет про сортировку взят, чтобы привнести единообразие в работу. Грубо говоря, дедлок появляется, когда нет согласованности в работе. Если оба выполнят UPDATE X, Y (в таком порядке), то дедлока не будет т.к. один из них сможет взять все блокировки на строки успешно. Поведение второго будет уже зависеть от уровня сериализации:
- Read committed - обновит новые данные
- Другие (repeatable read, serializable) - ошибка выполнения
Это уже детали MVCC в postgres (read uncommitted нет)