Так actual time для планировщика не имеет никакого значения...

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

до пересоздания (время фактического выполнения запроса)

 (371 rows)
real  0m0.050s

после пересоздания (время фактического выполнения запроса)

(371 rows)
real  0m1.046s

т..е. грубо говоря 20кратная разница

Yaroslav, спасибо за подсказки и помощь. Ну и по крайне мере сейчас постгрес совместимый с 1С ведёт себя как и ванильный, это уже снимает часть вопросов;

Вряд ли, к сожалению.
Учёт времени выполнения при планировании запросов вообще практически бесполезен (как ни странно), мне кажется. ;)

 (371 rows)
real  0m0.050s

(371 rows)
real  0m1.046s

Так в этом и дело — оценки не совпадают с реальностью (не в плане выходной cardinality этого node, а в плане оценки стоимости использования индекса).

Да не за что. ;)

вот и хочется чтобы планировщик постгреса каким-то образом научился обходить такие ситуации. я бы понял если бы разница фактического выполнения была +/- 20%, но не в 20 раз))

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

FOREIGN KEY оно?

ON DELETE CASCADE

Пасиб

Хочется, да. Только не совсем понятно, почему оценки именно такие (были бы именно эти данные на vanilla, можно было бы и покопаться... но совсем не факт, что нашлось бы что-то "интересное").
Хотя разница в "Buffers: shared read(hit)" между запросами тут очень приличная.

Вообще, чем больше условий (x AND y AND z ...), тем ниже оценка rows, и тем меньше и разница в оценках при "аналогичных" методах доступа (т.е. index scan по разным индексам, как тут, например). И это плохо для выбора плана.

Кстати, и какие-либо статистики в данном случае вряд ли помогут, на первый взгляд:

Index Cond: ((_period = (max(t4._period))) AND (_recordertref = (substr(max((t5._recordertref || t5._recorderrref)), 1, 4))) AND (_recorderrref = (substr(max((t5._recordertref || t5._recorderrref)), 5, 16))))
        Filter: ((t4._fld4493rref = _fld4493rref) AND (t4._fld4492rref = _fld4492rref) AND (t4._fld10536rref = _fld10536rref))

В этом условии, вроде бы, констант вообще нет. :(

Index Cond: ((_period = (max(t4._period))) AND (_recordertref = (substr(max((t5._recordertref || t5._recorderrref)), 1, 4))) AND (_recorderrref = (substr(max((t5._recordertref || t5._recorderrref)), 5, 16))))
        Filter: ((t4._fld4493rref = _fld4493rref) AND (t4._fld4492rref = _fld4492rref) AND (t4._fld10536rref = _fld10536rref))

всё что я указал - делалось на чистом ванильном постгресе 12.3

Ох, а я почему-то подумал, что это опять postgres pro или postgres + патчи от 1С, извините. ;)

нет)), я вначале указал что постгрес с поддержкой 1С стал вести себя как ванильный постгрес. И именно такое поведение уже ванильного постгреса меня крайне смутило)

Всем салют! Подскажите по UNION ALL.
https://www.db-fiddle.com/f/4o5uV5nXLeSkofb5zK2U3U/1
Мне необходимо реализовать save-or-get через один запрос к БД.
Я использовал INSERT {data} RETURNING * union all SELECT WHERE {data}.
Ожидаю, что
1) при вставке значения insert returning вернет строку, select where вернет строку
2) если запись существует - только select where
В итоге бекенд получает 2 строки если была вставка, 1 строку если существует.

В реальности INSERT {data} RETURNING * union all SELECT WHERE {data} всегда возвращает одну строку.

Где я ошибся и как без изменения структуры БД (и желательно моделей в ОРМ) получить признак INSERT неINSERT?

Ребята, можно ли написать оператор IN (select col1, col2, col3 ). Нужно как то перегнать 3 колонки в массив что бы его сьел IN?

select *
from hehehe
where ( col1, col2, col3 ) in ( select fld1, fld2, fld3 from gygygy );

Не оно?

А где здесь conflict-то? У Вас же его никогда не происходит, нет?