https://explain.depesz.com/s/um8x - вьюшка

А почему там "SELECT DISTINCT"?

Я к тому, что почти всегда это намекает на ошибку в запросе, которую кто-то пытается "замести под ковёр".
Т.е. если это действительно ошибка, зачем дальше разбираться (не вижу смысла оптимизировать неправильные запросы)?

по таблице meth.route_transfer, которая самая последняя по запросу возвращаются несколько записей.

И поэтому из них выбираются произвольные производные записи?
Это и есть попытка "замести проблему под ковёр", нет? ;)

Т.е. если возвращается несколько записей, то стоит подумать, значения из какой (или какие, если их надо группировать — максимумы/минимумы и т.п.) нужны в результате и почему.

сейчас с помощью lateral отбиру только 1 запись, уберу disitnct

Хорошо. А потом, если проблема останется — всё же, покажите всё, о чём я спрашивал (можно без \d таблиц, для начала).

https://explain.depesz.com/s/o3Ym - explain analyze запроса
https://explain.depesz.com/s/fh5w - вьюшка

после того как убрал distinct время выполнения лучше стало.
но все равно условие сразу не ставится и тем более не по индексу, и отрабатываются все записи

(Грустно вздыхая) И в третий, кажется, раз:
"Покажите версию PostgreSQL, запрос, \d каждой используемой таблицы, EXPLAIN (ANALYZE, BUFFERS)."

версия PostgreSQL 11.8 on x86_64-pc-linux-gnu
https://explain.depesz.com/s/8ooc - explain analyze buffers запроса
https://explain.depesz.com/s/fh5w - вьюшка
до этого писали что можно без таблиц, поэтому и не делал...тем более их много же

Я подчеркнул/выделил то, что Вы несколько раз подряд не показали, вот и всё.

да, этого слова BUFFERS не увидел сразу

Я же не просто так просил / повторял. ;)
По вопросу, вот это:

> шерстит все соединения которые дают 130 тыс. записей, потом по условию t.column = '112233' - оставляет 6 тыс.записей

Происходит вот из-за этого:

date(MAX(vd.marked_on) FILTER (WHERE vd.is_new) OVER (PARTITION BY dl.id)) AS rebuild_date,

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

date(MAX(vd.marked_on) FILTER (WHERE vd.is_new) OVER (PARTITION BY dl.id)) AS rebuild_date,

спасибо большое,
буду "курить" этот момент/поле

И это только одна проблема.
У Вас в запросе слишком много JOINs для стандартных настроек, что может [очень] плохо влиять на планирование.
Попробуйте потом (только для тестирования!) сначала получить план как обычно, а потом:

SET from_collapse_limit = 20;
SET join_collapse_limit = 20;
EXPLAIN (ANALYZE, BUFFERS) SELECT ...

И проверьте, меняется ли план вообще (если нет — повезло, если да и становится намного лучше — то это следующая проблема).

SET from_collapse_limit = 20;
SET join_collapse_limit = 20;
EXPLAIN (ANALYZE, BUFFERS) SELECT ...

ну наверное сначала поставить 15, потом 20 ?
а если план изменится в лучшую сторону после 15 (20) - так же можно наверное оставить? в других местах боком не должно выйти .

Зачем 15 ставить-то (толку от этого нет)? Либо этих параметров "хватает", либо нет, грубо говоря.
Ах да, и geqo_threshold тоже увеличьте до 20 или более (забыл написать).
Вам же просто нужно один раз узнать, есть ли проблема в самом планировании (планировщик может тупо не находить лучший план, потому что не выполняет исчёрпывающий поиск).

> в других местах боком не должно выйти .

Про "другие места" я ничего не писал. ;)
Изменяйте только в той сессии, где тестируете (я думал, что понятно это написал), конечно.

понятно.
я имел ввиду такие настройки на постоянно если оставлять

Нет, для "постоянно" это слишком (если есть много подобных запросов)... хотя, с другой стороны, если много подобных запросов, то у них могут быть схожие проблемы. ;)
Кроме шуток, на современном "железе" их можно поднять до 12 без проблем (а то и до 14, зависит от количества индексов и т.п.).

буду смотреть, сравнивать. спасибо

Здравствуйте, уважаемые участники группы.Помогите,пожалуйста, советом, я аналитик, которому дали доступ к базе на PostgreSQL , но мне кажется у меня что-то с правами. какую таблицу бы я не создавала (data studio), не будет ни одного айди юзера кроме doadmin. Подскажите, пожалуйста, мой ли это косяк или на стороне того,кто выдавал доступы