Поиск/индексирование по всем полям всех таблиц

Добрый день!

Есть база Postgres, а над ней создан интерфейс, который позволяет все таблицы фильтровать по любым полям разными операторами (например, =, >, <, содержит, начинается и т.д. (набор для каждого поля зависит от его типа)).

Есть ли в Postgres механизмы для поиска по любой комбинации условий/полей?

Индексировать каждое поле (или общий составной gin/gist) - не особо вариант, так как есть вполне большие таблицы с большим количеством столбцов, и каждый индекс в районе 1ГБ выходит. Да и накладно всё это получается при операциях записи.
Полнотекстовый, наверное, здесь не очень подходит, так как фильтрация может быть и достаточно простая, типа по числу, булеву и т.д. Да и нет тут задачи именно в текстовом поиске. Скорее, конкретные значения (или их наличие внутри).
Если сторонний механизм, то хочется, чтобы он был настолько интегрирован, чтобы обычный sql из любого источника использовал этот механизм для поиска.

Поделитесь, пожалуйста, какие есть варианты, чтобы можно было быстро (желательно, нативным sql) фильтровать таблицы по любой комбинации условий по любым полям.

Спасибо!

0

Сообщение от program_mister чтобы можно было быстро (желательно, нативным sql) фильтровать таблицы по любой комбинации условий по любым полям.

Динамический SQL ("клеить" запрос как строку) + индексировать по селективным полям. (например, строить индекс по полу М/Ж смысла не имеет )

0

Сообщение от PaulWist индексировать по селективным полям

То есть вы предлагаете каждое поле индексировать? По "м/ж" вполне тоже имеет смысл, так как в больших таблицах это тоже очень медленно работает. Пробовал на таблице с десятками млн записей.

0

Сообщение от program_mister То есть вы предлагаете каждое поле индексировать? По "м/ж" вполне тоже имеет смысл, так как в больших таблицах это тоже очень медленно работает. Пробовал на таблице с десятками млн записей.

Нет, вы невнимательно прочитали, я предлагал индексы по селективным полям, ... а вообще, выбор индексов должен быть выбран по статистике запросов, пример выбор по Фамилии будет скорее всего чаще чем по Отчеству -> строим индекс по ФИО, а не ОФИ.

Второе, по "м/ж" строить индекс не имеет смысла, поскольку средне статистически половина таблицы бедет М, другая половина Ж, соотвественно оптимизатор даже при наличии индекса выберет просто сканирование таблицы.

0