Да, конечно. Это же фундамент всех ACID СУБД — с т.з. пользователя в них всё атомарно (кроме того, что преднамеренно сделано не атомарным — sequences).

спасибо

Некоторые "куски кода" с wCTE Вы просто иначе не перепишете, кстати (те, где играют роль immediate constraints, например).

Всем привет, у меня есть такой относительно дорогой запрос:
SELECT c."chatId", c."sourceType", c."sourceId", cu."userId" as "responsibleUserId", c."unanswered"
FROM "contacts" AS c
LEFT JOIN "crmUsers_amocrm_v3" AS cu
ON cu."integrationId" = '00000000-0000-0000-0000-000000000000' AND c."chatType" = cu."chatType" AND c."chatId" = cu."chatId"
WHERE c."accountId" = 91000112 AND c."unanswered" > 0 AND c."deleted" = false
GROUP BY c."chatId", c."sourceType", c."sourceId", cu."userId", c."unanswered"
Я пытаюсь понять как его можно оптимизировать через explain analyse, получаю вот такой план - https://explain.depesz.com/s/hclB.
Если честно не сильно разбираюсь в индексах и как их правильно применять, но планирую добавить вот такой индекс - CREATE INDEX contacts_account_id ON contacts (accountId) WHERE unanswered > 0 AND deleted = false, это ускорит выполнение моего запроса?

А можно вставить план нормально не в JSON, и EXPLAIN (ANALYZE, BUFFERS)?
И какая это версия PostgreSQL?

вот так будет выглядеть два CTE  с точки зрения СУБД
P1-S1 - одна неявная транзакция, P2-S2 - вторая неявная транзакция

А вот это отношение поддержано индексами ? Что-то не увидел этого в плане запроса

Версия PostgreSQL 11.9, https://explain.depesz.com/s/nLLP

Вроде как нет

Я написал "не JSON".
Дело в том, что Вы либо вставляете как-то криво, либо сайт вообще не читает оценки из плана (а уж читать сам JSON как-то не хочется).

Ну там вроде как тест можно выбрать, вы про это?

Очень часто такое забывают, что foreign key != index, попробуйте создать индекс по полю FK

Я про то, что Вы должны сделать текстовый план и вставить его туда.

А это — практически мусор. Вы сами не видите, что тут все estimations нулевые (т.е. это "битый" план)?

Чтобы сделать текстовый план я же долже выбрать формат текст?

Вы должны в psql выполнить "EXPLAIN (ANALYZE, BUFFERS) SELECT ..." и вставить результат на сайт.

Коллеги, привет, посоветуйте стратегию, как и куда лучше покопать на тему vacuum?
Пользуемся SAAS решением, то есть доступа к конфигу на запись нет, можно попробовать просить вендора.
Имеем ситуацию: в таблицу в ~120М строк раз в полчаса приходит запись порядка 100-1500 строк insert/update, и вместе с тем раз в сутки приходит  порядка 1.5-3М insert/update пачками по 10К записей и около 100К-300К delete.
Параллельно 24/7 таблицу читают десятки процессов. Обратили внимание, что запускаемый руками раз в сутки vacuum analyze на таблице работает с полчаса.
Сейчас настройки такие:
<pg_settings name="autovacuum_analyze_threshold" value="50"/>
<pg_settings name="autovacuum_analyze_scale_factor" value="0.05"/>

Очень хочется понять есть ли вообще смысл запускать vacuum analyze руками, или это гиблое дело можно сразу бросать и нужно просить вендора тюнить конфиг сперва? И как бы понять в какие значения есть смысл тюнить конфиг?

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

vacuum analyze наносит пользу?