Всем привет.

Есть таблица с большим числом полей, каждое из которого хранит или NULL или 1. Других значений не бывает.
Строки - это товары, столбцы - атрибуты товара. Таблица генерируется динамически после изменений каталога и предназначена специально для получения агрегированных данных. Изначально планировалось получать кол-во товара по каждому атрибуту.

Пример: есть столбец "цвет синий" и сумма всех записей по этому столбцу - даст нам кол-во товаров с этим атрибутом.

Все прекрасно, но в какой-то момент кол-во уже не играет роли, а играет роль сам факт хоть одной записи с заданным атрибутом. То есть SUM не нужен, достаточно хоть одного значения в столбце NOT IS NULL, чтобы вывести в результат агрегации 1 или NULL (или 0).

Собственно есть ли функция, работающая по такому принципу? Чтобы она не анализировала ВСЕ записи как это делает SUM, находя сумму, а по факту совпадения любой записи с заданным условием - давала результат игнорируя остальные записи?

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

COUNT чуть быстрее, но незначительно. Суть в чем: что SUM что COUNT проверяют все записи, а я ищу некое решение (или функцию) которая будет выдавать результат при первом совпадении, без анализа все строк. Т.е. нужно не кол-во, а факт хотя бы одной строки у которой искомый атрибут не NULL.

Например, есть 1000 строк. У первой строки столбца "цвет синий" - стоит 1. Нет смысла проверять остальные строки, т.к. результат нужен вида "есть хоть один товар с таким атрибутом или нет".

Например, так работает AND в большинстве ЯП: если у нас есть условие cond1 AND cond2 AND cond3 и при этом cond1 вернул FALSE, то остальные условия не проверяются, т.к. наличие FALSE уже делает невозможным возврат TRUE для всех условий объединенных AND. Вот что-то подобное я и хочу получить: некая функция или трюк с выражением, чтобы в выборке по столбцам игнорить их перебор после первого совпадения со значеним равным 1. Я не уверен что такое возможно поэтому и спрашиваю.

EXISTS для подзапросов же.

Попробую объяснить на примере, есть таблица:




select sum(attr1), sum(attr2) - текущий вариант

Но SUM не нужна, нужен факт наличие в столбце хоть одного ненулевого значения. То есть в случае с attr1 достаточно проанализировать первые две строки чтоб выдать результат "есть ненулевые значения" и дальнейшие значения по данному столбцу можно игнорить. По второму столбцу - да, придется проверить все чтоб понять что ненулевых нет. Но столбцов много и если есть механизм подобного игнора анализа данных столбца при первом вхождении искомого значения - то должен быть прирост производительсности.

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

Да, нужны все сразу. Вертикальное хранение дает худший результат по производительности. Но я понимаю о чем вы, пару SUM работают в два раза быстрее чем пара сотен SUM. Может есть способ указать типа "применить агрегатную функцию ко всем столбцам" и это будет быстрее, чем перечисление всех полей?

В свое время 10 миллионов атрибутов при вертикальном хранении у меня работали достаточно быстро, чтобы поиск по ним занимал меньше секунды.
Кроме того "вертикальное"хранение хорошо тем, что не изменяются запросы при добавлении новых атрибутов.

Записей не так уж и много, сейчас запрос занимает примерно 70 ms, я бы хотел сократить это время. Тестирование с вертикальным хранением были больше 100 ms.

MAX, MIN, AVG - медленнее COUNT и SUM

1. Используется ENUM с одним вариантом 1 и NULL для пусто. Структуру делал не я, но как понимаю были разные эксперименты т.к. остановились именно на таком не совсем стандартном варианте как более быстрым.

2. Таблица живет в ОЗУ, у хостера только SSD

Я просто надеялся что есть какой-то трюк с помощью которого можно как с EXISTS проигнорить большую часть анализа значений, но похоже такого ничего нет. Да, время некритично большое, но увидев как можно избежать проверки всех значений, загорелся идеей сократить на этом время.

Спасибо за помощь!