ScareCrowAlexander Ryndinпропущено...
По первичному ключу.
и что мешает взять вдвое/втрое больше записей, чем нужно для показа, фильтрованных по паре/тройке наиболее селективных условий, а потом приджойнить к ним нужное?
Дело в том, что все джойны, которые здесь обсуждались, как раз-таки и нужны для того, чтобы определить записи, которые можно показать. Т.е. джойны делаются по тем условиям, которые имеют значения для отбора. И всё это обсуждалось для формата хранения данных EAV. Вы, как я понял, когда говорите "приджойнить к ним нужное" - имеете в виду приджойнить имя пользователя и т.п. Но это и не обсуждается, естественно, это делается когда уже ясно - какие пользователи подходят а какие нет.
То есть ваш вопрос похоже вызван тем что вы как-то иначе себе представляете исходное условие задачи.

web_foxПокажите, пожалуйста, лучший по времени EXPLAIN ANALYZE каждого из трёх вариантов запроса (только на одинаковых данных c одинаковым поиском) с сортировкой, которую хотели, и т.п.:
1. Через отдельные колонки (там, где bitmap-скан будет).
2. Через intarray.
3. Через bit string.
О кей, на днях постараюсь это сделать. Пока что урывками (т.к. увы очень мало свободного времени) тестирую более тщательно и в том виде, как это будет выглядеть на практике, вариант с фуллсканом. На данный момент могу сказать, что миллион записей в данном случае - это пожалуй крайний предел. Уже на полутора миллионах думает около минуты. Так что если число пользователей подойдет к миллиону (эх, чем черт не шутит), придется думать снова :).

AnyaNartovaА почему-бы вам не обратить внимание на СУБД которые хранят данные по колонкам? На Sybase IQ например?
Спасибо! Вполне возможно, что в будущем воспользуюсь для для этой или других задач.
Ну а пока что вполне приемлемым оказалось решение на PostgreSQL - для каждого атрибута своя колонка (а не все поля в битовой строке, как я пытался в предыдущем варианте), ну и не забывать про экономию места, чтобы больше данных влезло на страницу - например использовать тип "char" вместо smallint, поля по возможности null-able, и частичные индексы (учитывающие только не null значения) .
Поскольку у меня данные состоят по большей части из флагов, получается довольно компактно, т.к. в случае если флаг не установлен, то он и места не занимает (ибо null). То же самое с целочисленными данными. То есть хотя возможных атрибутов и довольно много, всё-же (учитывая статистику именно моих данных) более компактно получается с отдельными полями, чем с битовыми строками (особенно если учесть, что они хранятся в Postgre с приличным оверхедом). Ну и частичные индексы тоже занимают намного меньше места и следовательно работают быстрее.
В общем, на десяти миллионах это всё работает вполне шустро, и сложность запроса особой роли не играет.
Единственно, понадобились некоторые ухищрения для того, чтобы индексы реально использовались планировщиком в ситуации, когда нужно вернуть результаты в отсортированном по id виде (то есть с указанием order by id desc). Индексы, во-первых, должны быть составными, такого типа:
и во-вторых, в условии запроса нужно для каждого поля нужно не просто указывать желаемое значение, а с заклинанием IS NOT NULL, например:
, ну а для флагов просто IS NOT NULL (или IS NULL, если нужен сброшенный флаг), а не true/false.
Вполне возможно, адепты PostgreSQL найдут здесь какие-нить вопиющие косяки, но я в ней нуб, что поделать, во всяком случае пляска с бубном дала вполне приемлемый результат.