ощущение что постгря не видит мои новые индексы

перезапустил контейнер, заработало 🤷‍♂️

другое дело

Так это же другой запрос :) (на том же запросе проверьте)

он же

А, ок. Я с вот этим сравнивал.

Условия фильтров разные

у меня уже конечно 3ий час ночи, но разницы я не ыижу)

В одном у вас просто send_at > 999999, как я понял, с учетом того, что индекс по части таблицы (deleted_at, created_at). Там индекс не используется, что вполне может быть ок.
Далее вы говорите, что перезапустили контейнер и выполняете запрос с условиями индекса deleted_at, created_at, и send_at > 1

Это совершенно разные запросы для этого индекса.

вот я выполнял ранее аналогичный запрос с тремя условиями

изначально с ним у меня проблема и возникла, все остальное - это уже проверки чтобы докопаться до истины

Мне кажется, вам уже ответили, у вас скорее всего была неактуальная статистика/неподходящие конфиги постгри/неактуальная статистика + неподходящие конфиги постгри, на основе которых пг, высчитывая, как лучше получить результат, принял решение о том, что лучше сканировать всю табличку.

статистику я перестраивал командой analyze и vacuum analyze, других вариантов не знаю.. в конфиги не лазил, если знаете в каком направлениии рыть в конфигам, подскажите, буду благодарен

Вы же недавно выполнили запрос и все у вас сработало?

да, перезапустил докер контейнер с postgresql

Ребята, как правильно сделать апдейт выборки по условию
суть - выбрать рандомные записи в большой таблице. Использую этот подход с простор интернета, работает гарааааздо быстрее random()
Но вот как работать с данными пока не понял... Как их проапдейтить, или вставить в временную табилцу…

WITH params AS (
    SELECT 1       AS min_id           -- minimum id <= current min id
         , 12005000 AS id_span          -- rounded up. (max_id - min_id + buffer)
    )
SELECT *
FROM  (
    SELECT p.min_id + trunc(random() * p.id_span)::integer AS id
    FROM   params p
          ,generate_series(1, 101000) g  -- 1000 + buffer
    GROUP  BY 1                        -- trim duplicates
    ) r
JOIN   ivr.livenumbers USING (id)
where flag1 is null
LIMIT  100000

WITH params AS (
    SELECT 1       AS min_id           -- minimum id <= current min id
         , 12005000 AS id_span          -- rounded up. (max_id - min_id + buffer)
    )
SELECT *
FROM  (
    SELECT p.min_id + trunc(random() * p.id_span)::integer AS id
    FROM   params p
          ,generate_series(1, 101000) g  -- 1000 + buffer
    GROUP  BY 1                        -- trim duplicates
    ) r
JOIN   ivr.livenumbers USING (id)
where flag1 is null
LIMIT  100000

можно использовать сэмплирование: select tablesample for update -> update

Добрый вечер! Наткнулся на следующее умозаключение:
———————————————-
Какие отличия между ограничениями PRIMARY и UNIQUE?
По умолчанию ограничение PRIMARY создает кластерный индекс на столбце, а UNIQUE - некластерный.
———————————————-
Насколько понимаю - это ошибка. Каким это образом юник может создавать некластерный индекс?

А что именно из докеризованного postgesql с базой нужно хранить в volumes?