web_foxВасисуалий Пупкинсон,
создадим для теста таблицу
........

Спасибо! Завтра помедитирую над этим.

web_foxCREATE INDEX "table1_idx" ON "public"."table1"
USING gin ("property_arr" "public"."gin__int_ops");[/src]

Вот, наконец, дошли руки продолжить эту задачу. Попробовал испытать этот способ, но получаю ошибку:
"ERROR: operator class "public.gin__int_ops" does not exist for access method "gin""

Если я правильно понимаю, это значит что модуль intarray не установлен. Посмотрел в доках, там написано, что нужно запускать gmake для этого, если модуль не установлен, а если установлен, то скрипт из папки contrib. Но у меня в этой папке скрипта для intarray нет (т.е. похоже, что этот модуль нужно скачивать отдельно, но что-то нигде не видно, откуда его можно скачать), да и вообще, postgres (9-й) у меня сейчас установлен на Windows, да и без исходников.
Вобщем, что-то я с этим застрял. Если не трудно, подскажите, пожалуйста, что тут надо сделать, чтобы на gin__int_ops не ругалось, я просто с postgres до этого дела не имел вообще...

web_foxВасисуалий Пупкинсон,
у меня тоже на виндовс. Для виндовс достаточно просто запустить файл C:\Program Files\PostgreSQL\xxxxxx\share\contrib\_int.sql.
О, спасибо, сработало. Файл этот у меня есть, я просто думал, что он должен называться intarray.sql.
Жаль, что такой штуки нет для типа smallint, заметная экономия места была бы, да и ускорение опять-же.

ScareCrowя вот уже 4 страницы не понимаю этот цирк. расскажите для кокой хотя бы немного реальной задачи нужно джойнить между собой 30 раз по миллиону записей?

Дык вот, поиск пользователей... 30 раз и миллион записей - это конечно не так уж чтобы совсем реально, но всё-таки хотелось бы иметь определенный запас прочности, чтобы даже и при таких условиях приложение давало ответ за более-менее разумное время.

На данный момент ситуация такова - попробовал разные способы, предложенные уважаемыми коллегами в этом топике, подходящий вариант найти трудно, т.к. сильно осложняет дело то обстоятельство, что результаты нужно выдавать в отсортированном виде (по времени регистрации пользователя), страницами. Если бы всё сводилось к тому, чтобы выдать просто некоторое количество любых пользователей, подходящих под указанные критерии, то отлично работал бы способ с gin индексом по intarray, предложенный web_fox-ом. Но в случае если подходящих под условие строк оказывается очень много, то серверу приходится сначала выбрать их все, отсортировать, и лишь потом выдать определенную порцию. И это сразу всё тормозит. Что касается gist индекса, то он не показывает особенно впечатляющих результатов.
Пробовал MongoDB. Вопреки ожиданиям, скорость поиска тоже не ахти. Использовал подход с Multikeys. То есть две колонки - _id (int) и а (массив int-ов длиной 100 элементов). Индекс по a. На миллионе записей запрос на наличие в атрибутах 6-ти указанный чисел выполняется секунд 40. Запрос такой:
Смотрел explain, индекс используется. Черт его знает что за фигня, вроде всё правильно сделал... По идее, эта БД как раз ведь для таких задач и заточена...

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

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

Памятуя о неоднократных советах, данных в этом топике, использовать сквозное сканирование, как последнее средство решил испытать и это. И что вы думаете? Успех!
Испробовал вариант с битовой строкой длиной 250 бит (это в PostgreSQL), в котором каждому атрибуту соответствует определенная позиция в строке (дело в том, что у меня подавляющее большинство атрибутов - флаги, или можно свести атрибут к набору флагов).
Строк - миллион. То есть два поля - user_id и битовая строка. Коэффициент заполнения страниц поставил 100%, чтобы поплотнее запихнуть. Работает меньше секунды даже если нужно просмотреть всю таблицу. Конечно, надо было гораздо раньше это испробовать, но как-то интуитивно казалось, что при такой ширине строки перебор будет занимать всё-же слишком много времени.
Сегодня потестирую это более основательно, и если всё ок, не вылезет никаких граблей, то наверно на этом и остановлюсь, ибо просто и надежно. Да и запас прочности хороший.