это очень сильно удорожает программирование

есть ультимативный пример - ВК писали специальные базы данных под задачу, они у них "движки" называются(лись)

nosql где-то посередине между кастомным хранилищем и sql бд

Согласен, но тюнить black box под тоже недёшево. Слишком много магии

ну когда-то наступает "взрослость" задачи(проекта), когда уже можно nosql и влить деньги в моделирование данных

Когда наступает взрослость нужен DDD и bounded context. Технологии это уже второй вопрос

А где почитать об этом можно?

у них даже на гитхабе был код кажется

а вообще я на хайлоаде был на докладе, могу попозже найти

Ага, спасибо!

Я ненастоящий постгречник, но это ожидаемо.

У тебя две опции:
-создать второй такой же индекс, но сортированный в обратном порядке

- брать людей подзапросом и потом его сортировать.

Ps. Подзапрос может не сработать, ибо шибко умный бд-сервер может прочухать и переписать запрос по-старому. Это редкий кейс, но есть грязный хак - сделать в подзапросе «top 100000» чтобы он материализовался первым))


PPS в sql server такое решается одним словом “forceseek”. Может в пг тоже есть индексные хинты?

В мускуле есть use_index/force_index модификаторы btw

в mysql есть USE INDEX кста

ну тут сошлось все в одной точке - и странный юзкейс и старый посгрес и отсутвие (почти)  хинтов.

но ваще да, это мне положено все в посгресе делать, но рормальным людям - нет )

Я ж говорю, в постгре нет индексных хинтов. Если не считать таковыми ORDER BY id*1.

Ну какой же это странный юзкейс? Есть некие сообщения, адресат которых характеризуется двухкомпонентной строкой. Причём я не думаю, что эта двухкомпонентность реально роляет, мне кажется и с одиночным индексом было бы тоже самое. И надо получить последних 10 (20, 30, 50) сообщений для адресата.

это не поможет

create table t (id int);
create index on t(id);

explain select * from t order by id;
-- Index Only Scan using t_id_idx on t (cost=0.15..82.41 rows=2550 width=4)

explain select * from t order by id*1;
-- Sort (cost=186.16..192.53 rows=2550 width=8)
-- Sort Key: ((id * 1))
-- -> Seq Scan on t (cost=0.00..41.88 rows=2550 width=8)

нормализовать надо, тогда такой проблемы бы не было )

Можно сделать поле с датой получения сообщения и не делать индекс по нему. И делать сортировку не по id, а по дате. Тогда у постгри не будет соблазна использовать не тот индекс

Или даже копию id в колонке без индекса