Комментарии 9
Если честно, то я до сих пор не понимаю, почему такие оптимизации до сих пор отсутствуют в постгре. Наблюдаю эту проблему довольно давно из-за всяких ORM (django rest framework особенно добавляет жару). Тот же 1С, уверен, сильно бы ускорился, потому что там целая индустрия процветает, по оптимизации запросов.
Если вдруг протолкнёте это изменение в апстрим, то будет очень круто.
Нужны репорты и примеры из реальной жизни - у меня ж в основном синтетика, такими сложно убедить сообщество.
Могу предположить, что случаи, когда такая оптимизация востребована, относительно редки. То есть, либо проблема куда эффективней решаема статистиками или индексами. Либо используются columnstore решения.
Ну а проблемы ORM только этим не решите. Всё равно приходится использовать представления и функции, если производительность имеет значеие.
Оптимизацией запросов занимаются, если есть возможность их ускорить в разы. Ради 10% это, в подавляющем большинстве случаев, не рентабельно.
Хм, так эта штука почти бесплатная и не связана с другими оптимизациями. Так почему бы не иметь? А columnstore избавляет только от одной проблемы: сортировать по селективности все же имеет смысл независимо от движка.
Так почему бы не иметь?
Так я не против такой оптимизации. Но корячится месяц на написание патча и его пропихивание в мэйнстрим, ради 10%, возникающих раз в год на кривом запросе - я точно не буду. Потому и подозреваю, что таких желающих просто не находится.
Если Вам это действительно надо - пожалуйста, разрабатывайте такой патч. Я даже поддержу.
А columnstore избавляет только от одной проблемы: сортировать по селективности все же имеет смысл независимо от движка.
Зачем? В columnsore по определению фильтрация выполняется по столбцам. Там нет кортежей, а значит и нет проблемы последовательности анализа полей в кортеже.
Хм, так вроде код готов - я только потому и пишу обычно на хабр, чтобы получить фидбэк на фичу, а не проект. Времени на него ушло - 1 день. В апстрим продвигать действительно долго, но там я не коммитер а просто контрибьютор: написал, добавил на коммитфест и все Примут - хорошо, не примут - мне для коммерческого форка и так сойдёт.
В columnstore вероятно нет проблемы последовательности полей - хотя я и не проверял. А вот сортировка по селективности - с ней-то что? Вроде бы пока ещё условия не вычисляются параллельно, а значит всегда есть смысл уменьшить количество вычислительных операций. И тут даже JIT не снизит эффект.
В апстрим продвигать действительно долго
Я и написал - месяц. И это еще если не будет обнаружено что-то, проявляющее себя отрицательно где-то в совсем неожиданном месте. Навскидку, например, с TOAST.
добавил на коммитфест
Ссылку дайте. Обещал поддержать - постараюсь, хоть я тоже не коммитер.
В columnstore вероятно нет проблемы последовательности полей
Точно нет, так каждое поле (колонка) хранится отдельно.
пока ещё условия не вычисляются параллельно
Где? В ClickHouse точно параллельно. В Citus - тоже. Сама идеология columnstore - именно в массовом параллелизме.
В ClickHouse точно параллельно
А при чем здесь он. Я только про Postgres пишу. Ну и по поводу остальных я сильно сомневаюсь - уж слишком мелкозернистый получается параллелизм, чтобы ещё x=1 OR x <10 вычислять параллельно. Я бы посмотрел в сылку на имплементацию такой штуковины. Даже в SQL Server распараллеливание сделано не вертикально (по выражениям), а горизонтально - по наборам туплов.
Ссылку дайте
Код есть, а отправлять пока рано. До июня засылать что-то в хакерсы - значит похоронить ибо народ сейчас релиз готовит, им не для новых фич.
А при чем здесь он. Я только про Postgres пишу.
Потому что в PostgreSQL нет поддержки различных систем хранения. Поэтому все ColumnStore решения для него реализуются через FDW. И в этом случае, что CH, что Citus - суть одна и та же.
чтобы ещё x=1 OR x <10 вычислять параллельно
Нет, конечно. Параллельно обрабатываются колонки. Но данный случай откровенно надуманный, так как множество, определяемое первым условием, является подмножеством множества, определяемого вторым условием.
А для корректного примера x>20 OR x<10 последовательность значения не имеет. Особенно с учетом наличия "пропускающего" индекса на гранулах.
О переупорядочении выражений в Postgres