LINUX.ORG.RU

Postgresql какой индекс выбрать


0

1

Есть необходимость сделать поле вида

varchar(16)[]

в нем будет массив значений от нуля до 5 записей (в среднем)

самое унылое что по этому полю надо еще и поиск делать

нужны поиски вида:

«выбрать все записи у которых меньше N членов в массиве» - это вроде просто

«выбрать все записи у которых есть член 'abc' в массиве» - это уже не особо понятно как индексировать

и самое сложное

на входе массив

"abc", "def"

а в столбиках массивы:

"abc", "abd", "def"  - должно вернуть 2
"abc"                - 1
"def", "abc"         - 2
"eaf"                - 0

и соответственно отобрать всех у кого скажем число меньше или равно 1

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

BTREE вроде не ложится на работу с битовыми масками? HASH тоже

но в разные столбики не упихать (чтобы BTREE работал), поскольку количество хоть и ограничено (в максимуме пара десятков) но всеж большое

★★

Ответ на: комментарий от anonymous

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

а конкретнее?

по битовым строкам эффективных индексов нету вроде, а по массивам можно только по определенному элементу сделать индекс

ни так ни сяк не выходит

rsync ★★
() автор топика

Можно вынести эти строки в отдельную таблицу и уже там строить btree.

friday ★★★
()

как предложил friday, рефакторить, и вынести это мракобесие в отдельную таблицу!!1адинадин. потому, что потом гарантированно появятся еще более изощренные запросы к этому полю, но уже будет только один выход - «помыться и в горы» ;)

aol ★★★★★
()
Ответ на: комментарий от namezys

лучше бы предложил изящный способ топикстартеру, м? ;)

aol ★★★★★
()
Ответ на: комментарий от anonymous

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

другого выхода как-то не видать

rsync ★★
() автор топика

> в нем будет массив значений от нуля до 5 записей

В отдельную таблицу, это классическое отношение «один-ко-многим».

Nastishka ★★★★★
()
Ответ на: комментарий от Nastishka

нельзя отдельную таблицу. будет ахтунг а не БД. дело в том что там рабочих таких таблиц уже около 40. если к ним к каждой 5-20 таблиц приделать будет пипец какой-то

rsync ★★
() автор топика
Ответ на: комментарий от rsync

> дело в том что там рабочих таких таблиц уже около 40. если к ним к каждой 5-20 таблиц приделать будет пипец какой-то

Значит, у вас куча классов с общей точкой в иерархии.

Значит, почти наверняка они процентов на 40 по полям перекрываются.

Значит, вам рано или поздно придется выносить эти общие поля в отдельную родительскую таблицу типа «Documents(ID,Creator,Status,DocNumber,DocType)».

И на эту родительскую таблицу и навешивать связь из таблицы дополнительных атрибутов.

Хотите делать, не хотите - разницы никакой. Все равно вы к этому придете и делать это вам придется, так что лучше делайте сейчас.

P.S.: родительскую таблицу для соображений обратной совместимости, можно заполнять триггером. Знаю, это костыль - но можно не переделывать всю схему и не переделывать клиентские приложения.

Nastishka ★★★★★
()
Ответ на: комментарий от Nastishka

И на эту родительскую таблицу и навешивать связь из таблицы дополнительных атрибутов.

родительская таблица уже организована, да. но организация индексов так и остается на таблицах дочерних.

rsync ★★
() автор топика
Ответ на: комментарий от rsync

но организация индексов так и остается на таблицах дочерних

Зачем? Для поиска по значениям полей? Если вам предстоит лепить запросы вида

select
   ...
from extenddoc d
join docvalues v on d.id = v.doc_id
where
    v.nvalue = :td1 and
    d.docfield = :td2
то оптимизатор при знании о распределении ключей заметно лучше справится с этим. Опционально, можно попытаться задействовать function-based индексы для функции вида getNthValue(docid,N). Тогда можно будет писать
select * from extenddoc where getNthValue(id,1) >= XXXX or getNthValue(id,2) >= XXXX

Nastishka ★★★★★
()
Ответ на: комментарий от Nastishka

Хотя обманула я вас. Индекс по функциям нельзя построить - эта функция точно не будет immutable, а для индексов другие не подходят :-/

Nastishka ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.