Коллеги, а есть ли способ заставить PG использовать конкретный индекс?

Причем, указать надо именно в SELECT, вещи типа set enable_seqscan=false не подходят.

нет

А если пойти таким путем - этот селект запихнуть в функцию и там установить enable_seqscan, а оттуда вернуть результат?

а что изменится?

В функции этот селект выполнится с использованием индекса, или я что-то не так понимаю?

почему он там должен с использованием индекса выполниться?

Потому что перед выполнением я поставлю переменную set enable_seqscan=false

так выключение секскана это не заставить использовать конкретный индекс. это просто заставить использовать индексы

У меня простой запрос, where identity_id = 45, к примеру. Так как в таблице мало значений, то имеющийся индекс не используется. А надо, чтобы использовался.

Кому надо? Вам? Вы и используйте. Пг не надо.

надо разбираться, почему база принимает такое решение. в вашем случае из-за размеров таблицы выгоднее сделать SS, т.к. он затронет меньше страничек, чем IS на маленьких размерах (1-2 страницы по 8кБ) IS-ы редко используются

Это понятно, но я хочу заставить его использовать индекс даже если в таблице 2 строки - чтобы выбрал сразу нужную и не лез бы ко второй.

мало это сколько? если там несколько сотен записей, то индекс не нужен, проще последоватлеьно прочитать.

данные хранятся в виде страниц, на которых множество строк записано. если все на одной странице умещается, то в индекс нет смысла лезть

вы механику работы IndexScan-а в базе понимаете? база работает с блоком, а раз он уже в кэше, то найти запись – пара лишних циклов то, что вы хотите — это надо лезть в как минимум ещё 2 дополнительных блока. это дороже. вы хотите странного

В системе используется защита строк. таблица, о которой я говорю, содержит разрешения на просмотр таблиц, в том числе и самой себя. Для этой таблицы имеется своя policy, которая пропускает стоку если она “текущая”(определяется по переменным сессии), а если не “текущая” - то загружается “текущая” строка и из нее берутся разрешения. Все работает, когда используется индекс - когда записей много, а когда мало - мроисходит, понятное дело, зацикливание.

хм, велосипед? https://www.postgresql.org/docs/current/sql-createpolicy.html

???

не понял почему происходит зацикливание, вообще ваш кейс звучит оч странно) наличия индекса только на производительность влияет, а не на корректность

Я про это и задавал вопрос - можно ли селект вынести в функцию и в ней отключить seqscan

пробуйте, но знайте, что вы что-то странное делаете и скорее всего некорректное. сейчас работает, завтра нет

Есть еще мысль-сделать то поле, по которому поиск, PRIMARY_KEY. Правильно ли я понимаю, что по PK он выберет всегда одну запись и не будет делать SEQ SCAN ни в каком случае?

нет

Почему?

расскажи что за защита строк, которая зависит от способа сканирования?

я же расписал механику на пальцах — зачем лезть в индекс, если таблица из одного блока? поход в индекс в 3 раза увеличивает работу для таблицы из 1 блока.

Я же написал - ест таблица, в которой есть дескрипторы - некие числа, которые определяют, можно или нет данному юзеру показывать конкретную запись. Потем сравнения этих дескрипторв с колумном в каждой строке таблиц, котрые под защитой строк. Таблиц много, все работает, но также надо, чтобы под этой защитой строк оказалась и сама таблица, где дескрипторы прав.

а я написал, что вы велосипед изобретаете – этот функционал есть в базе. и дал ссылку на доку

То, что Вы написали, мы и используем. Я писал - запрос используется в policy

Как должны провериться права на таблицу, если они лежат в этой таблице?

ну окей, а почему это при послкдовательном сканировании не работает?

А что мешает это делать?

мне — логика

Бывает.

Я про саму логику действа. Вы хотите соблюдать права доступа при чтении таблицы, которую нужно прочитать для соблюдения прав доступа