в таблице.. на 100000 работает плохо. Как переделать под курсори? Я ще учусь буду рад помощи
А при чём тут / чем поможет "переделать под курсори"? Если же хотите помощи с оптимизацией запроса — https://t.me/pgsql/288632
Мне нужно реализовать пагинацию по таблице, понимаю что запрос говно. Потому хочу чтоб подсказали в каком направление двигаться, так как учусь
Но в этом запросе даже следов pagination нет... и при чём тут JSON, в таком случае? И да, насчёт pagination в принципе: https://use-the-index-luke.com/no-offset
Ну на беке я буду передавать limit offset и хочу получить данние в json. Не дописал вконце лимит оффсет. Спасибо за ссилку
"Ненастоящие" запросы нет смысла оптимизировать. Что нужно показать, чтобы Вам помогли с оптимизацией (реального запроса!), я уже писал. И делать это нужно именно на тех данных, где есть проблема, конечно.
Вот казалось бы берём b-tree, добавляем в каждый узел счётчик - кол-во узлов, которое равно сумме кол-ва узлов по всем детям. А у листьев это число равно 1. Далее можно быстро делать offset по такому изменённому дереву. Почему так никто не делает?
Потому что это никому настолько не нужно. Т.е. отношение затрат и выгод на практике никогда не в пользу такого решения.
Есть одна маленькая проблемка. Индексы не хранят информации о видимости строк, а значит с offset эти счетчики числа дочерних нод никак не помогут, если только мы не говорим о редком случае таблицы, в которую почти никто не пишет. Вкупе с проблемами, которые выше описали (блокировки при апдейтах вышестоящих нод), овчинка выделки не стоит.
В этом случае мог бы помочь кластеризованный индекс (если я правильно это назвал), но в pg нет такого почему-то, только heap.
Кластеризация не поможет идентифицировать неактуальные записи, а лишь даст упорядоченность индекса в соответствии с данными на диске
Не, вы похоже про команду cluster говорите, а я про то, чего нету в pg
Обсуждают сегодня