не из-за желания сэкономить места появились?
нет, это попытка ускорить фильтрацию, колонок много, разных значений мало, условия для фильтра зависят от пользовательского ввода. Было бы круто все условия на равенство объединить таким образом в 1, и получить индекс на 1 колонку
А как вы ускорения хотите добиться?
сравнивая 1 поле с битовой маской, вместо 1-20 полей с мелкими интами
Ну я ж выше спрашивал, не решили ли сэкономить на колонках. Сэкономили. Без индексов, без статистики, без конкурентных обновлений по полю, только всю строку под select for update. Редяционные базы такой подход не любят
оригинальные поля-то остаются) апдейтов по этим полям и не будет скорее всего.
Так если остаются, то по ним индекс ставьте
20 индексов по 1 колонке каждый?
Нет, смотрите на статистику запросов и под медленные ставьте. Сколько записей в таблице?
~300k да это понятно, просто хотелось радикально вопрос решить) Спасибо)
А чем char(20) не нравится? И апдейтить его при каждом изменении одного з 20 полей в строке :)
тип без разницы, но можно ли получить индексированный поиск по вхождению произвольной части такой строки?
Только непонятно зачем это все... Это же по сути вы просто вручную хотите создать композитный индекс... Думаете СУБД хуже вас это сделает?
композитный хорош когда поиск всегда по всем колонкам, а если юзер натыкал из 20 только 3, 8 и 17?
можно нагенерить декартово произведение значений 20 полей и сравнивать с ним... Единственный вопрос как рассматривать отсутствие фильтра пользователя в определенных полях (для этого тоже вероятно надо значение типа * или что-то свое в месте этого поля)...
А действительно будет реальный выигрышь от лишних телодвижений по сравнению с отдельными индексами?
заменить пустоту на 1, а остальные сдвинуть... Маска удлинится, но должно работать, спасибо за идею)
для более простого случая и полных совпадений, он был. Тут тоже должен быть, просто не понятно было как частичные вхождения проверять. Вы подсказали как сделать полные совпадения. Если будут интересные результаты, отпишусь)
звучит похоже на GIN индекс по вычисляемому выражению (например, массииву + array_ops)
тоже вариант, правда поле может жирноватым получиться, но попробую
Может быть, заодно посмотреть на https://www.postgresql.org/docs/current/bloom.html (не знаю, насколько это production-ready, правда...)?
почему-то именно эти индексы всегда мимо меня проходили) Их тоже попробую
Обсуждают сегодня