А есть где-то на человеческом языке почитать про выбор между delete where not exist, delete where not in и delete using + left join? Исходя из чего между ними вообще выбирают обычно?

not in VS not exists — это про составной ключ или ключ из одного поля,
DELETE + JOIN VS NOT IN , NOT EXISTS — это про отрицание. (так-то delete + join может заменять оба)

Добрый вечер.
Я вот не пойму как записать такую запись в pgadmin
Select * from "posts"
Where "posts"."createdAt" $gte('2021-03-10 15:00:46.123+00')

Плюс delete + JOIN нестандартный, а IN | EXISTS - везде одинаковые.

Потому что пишет что не понимает что такое $gte

Я тоже напр. не понимаю...

pg_locks для проблемного инсерта показывает mode=ShareLock relation=insert~_table_name, locktype=relation, те инсерт пытается получить ShareLock на таблице в которую вставляет

А есть какие то варианты что бы понимало условие  больше какого-то даты ибо в физерс все нормально понимает но когда прописать такое же в pgadmin то выдает ошибку

Вот у меня есть две таблицы: А и В. Между ними связь по полю f1, которое обязательно не null. Если я хочу из В удалить все, чего нет в А, то ведь любой способ из трёх валиден.

С составным ключём будет невалиден способ с not in в лоб, хотя можно и склеить разными путями, но два останутся. Бери какой ближе духу?

А что значит "relation=insert~_table_name" ?
Oid relation-a в который делается вставка?
А как вы понимаете, что этой блокировки ждёт именно бэкенд, который делает insert?

по двум источникам, по результатам выполнения запроса во время наблюдаемых проблем:
select
 now() as datetime,
 bgl.relation::regclass,
 bda.pid as blocked_pid,
 bda.query as blocked_query,
 bdl.mode as blocked_mode,
 bdl.locktype as blocked_locktype,
 bdl.granted as blocked_granted,
 bga.pid AS blocking_pid,
 bga.query as blocking_query,
 bgl.mode as blocking_mode,
 bgl.locktype as blocking_locktype,
 bgl.granted as blocked_granted
from pg_catalog.pg_locks bdl
 join pg_stat_activity bda
   on bda.pid = bdl.pid
 join pg_catalog.pg_locks bgl
   on bdl.pid != bgl.pid
   and bgl.relation = bdl.relation
   and bgl.locktype = bdl.locktype
 join pg_stat_activity bga
   on bga.pid = bgl.pid
where not bdl.granted;

и по логам  process 14235 still waiting for ShareLock on relation 22209781 of database 6415862 after 1000.041 ms

где 22209781 это oid  таблицы куда идет вставка

ну пока ни запрос, ни приведённые логи не доказывают что бэкенд 14235 выполняет именно insert.
А сделайте select * from pg_locks where mode='ShareLock';

relation            | blocked_pid |                                                          blocked_query                                                          | blocked_mode | blocking_pid |                                                 blocking_query                                                  |  blocking_mode
-------------------------------+-------------+---------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------------------------------------------------------------------------------------------------------------+------------------
delivery_order_metric_2021_03 |       10194 | insert into delivery_order_metric (creation_date, merchant_id, order_id, payload, pos_id, type) values ($1, $2, $3, $4, $5, $6) | ShareLock    |        31804 | SELECT commit_fk, property_name, property_value FROM jv_commit_property WHERE commit_fk in (37330559,37330558)  | RowExclusiveLock
delivery_order_metric_2021_03 |       10194 | insert into delivery_order_metric (creation_date, merchant_id, order_id, payload, pos_id, type) values ($1, $2, $3, $4, $5, $6) | ShareLock    |        31804 | SELECT commit_fk, property_name, property_value FROM jv_commit_property WHERE commit_fk in (37330559,37330558)  | ShareLock
(2 rows)

как раз логи имхо лучше всего это показывают process 14235 still waiting for ShareLock on relation 22209781 of database 6415862 after 1000.041 ms, для pid 14235 предыдущая запись в локах как раз инсерт

pid 14235 нигде не фигурирует, кроме сообщения из лога.
Я просил привести результаты вполне конкретного запроса...

(id:int PK, name : text UNIQUE, description:text) 

(name : text PK, description:text) 

Мне кажется, что и на несовременных это было не критично. ;)
В общем, это скорее всего, несущественно.

А почему запрос который я привёл и его вывод не подходит?