> Написать бы хоть в какую сторону.

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

Так вот, с учётом:

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

(Если Вы оставляете по 10 записей, то при 6M профилей останется максимум 60M записей.)
Быстрее было бы "перелить" то, что хочется сохранить, в новую таблицу, потом создать индексы, затем старую заменить на новую. Но всё это сработает, если есть возможность временно прекратить работу с таблицей (можно и без этого, но мороки больше).

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

Ну а это (когда нужно удалить совсем немного записей) — другое дело, конечно.

да, согласен. Вариант с перелить в новую таблицу не рассматривал, запомню, спасибо

композитный btree индекс по (profile_id, create_ts) я, кстати, добавлял, но разницы в explain не увидел. Возможно, это все старый постгрес, конечно. Или опять я чего-то не так делаю

Yaroslav @tzirechnoy @SashaTChe еще раз спасибо за брейншторм, сори если я тупил где-то - я не специально)

(глянул - уйдет 321,776,154 строк, если удалять те, где на профиль >1000. Что будет если 100 поставить - боюсь представить 😅)

Если задача чистить, то можно сначала выбрать список
select profile_id from payment group by profile_id having count(1) > 500
потом по этому списку идти и удалять платежи для данного профиля по 1 профилю в 1 транзакции.
Суммарное время будет неоптимальное, но и нагрузки на базу не будет

Вы поставили условие "одним запросом", а в вашей задаче такого условия нет

Вы, кажется, ни одного настоящего EXPLAIN (c production) так и не показали?

> Возможно, это все старый постгрес, конечно.

Скорее, это проблема tuning и т.п. ("заставить" PostgreSQL с настройками по умолчанию сканировать весь индекс вместо таблицы почти нереально).
Тем не менее, могли бы попробовать и вариант с LATERAL. И да, в любом случае именно этому DELETE стоит дать побольше work_mem (можно начать с 512MB), иначе "интересных" планов не получится. ;)

explain с production я за 30 минут так и не дождался, к сожалению :) ну и на проде добавлением индексов и экспериментами совсем заниматься не хочется, по хорошему пре-прод с дампом прода, и там уже играться... но, как я уже говорил... остальное приму к сведению, спасибо

Доброй ночи.
Ребят, можете помочь? Чёт туплю дико и не могу нормально написать

Есть тип:

MY_POINT 
( X real, Y real, ts timestamp )

Есть таблица:

 MY_TABLE
( id 
vehicle_id bigint,
point MY_POINT);

В таблице хранится ID машины и точка ( координаты х,у и время замера )

Нужно вывести данные о машине, но только самые последние

Как правильно сделать?
Как я понимаю, GROUP BY не подходит, а что другое можно ?

вывести данные по одной машине я могу:

SELECT * from  MY_TABLE  WHERE vehicle_id = <число>  order by (point::MY_POINT).ts desc limit 1

Yaroslav , выручай )

Я бы могу написать SELECT vehicle_id, max(point)
Вот только мне нужно именно максимальное по point.ts

Так, вроде нашёл

Можно сделать вот так:

SELECT vehicle_id, point
FROM TABLE
GROUP BY vehicle_id, point
HAVING (point).ts = max((point).ts)

последнее — явно что-то не то

select vehicle_id, first_value(point) over(partition by vehicle_id order by (point::MY_POINT).ts desc) as X from MY_TABLE group by vehicle_id, X
что-то такое

ещё вариант
SELECT vehicle_id, max(((point::MY_POINT).ts, point)) from MY_TABLE group by vehicle_id

этот не работает))

идея была — сделать тапл из 2 элементов, и по ним максимум. второй элемент на сортировку не влияет, но вам его выведут в результатах за компанию

возможно, это не компилируется из-за того, что для типа point нет операции <

select vehicle_id, point, row_number() over(partition by vehicle_id order by (point::MY_POINT).ts desc) as X from MY_TABLE  where X = 1

Well... myself vinod  joining from india...I don't know Russian language...hope I will get help on queries 😁

Looking forward to learning together.