Обновить

Комментарии 11

Спасибо за интересную статью!

Хотел уточнить по BRIN индексу проводилось ли упорядочение (сортировка) данных до построения индекса, если нет, возможно это причина его не использования?

Немного не понял, что имеется ввиду. Greenplum не умеет хранить отсортированные заранее данные. Насколько я знаю такая возможность есть только при использовании спецификатора CLUSTER, но он работает только с B-tree индексами и не поддерживается для партицированных таблиц.

На малом объеме данных BRIN сработал, видно из плана запроса, который я привел в статье.

А если на вход подать отсортированноу последовательность при создании таблицы партиции, insert as select order by.

Моя идея была в том, что в зависимости от сортировки данных селективность brin индекса меняется и это можкт учитываться в статистике и gporca.

идея хорошая, но, тогда надо и дополнительные накладные расходы обязательно учитывать. Замерять время вставки с сортировкой и без сортировки и потом делать выводы стоит ли оно того чтобы как в том мультике - "пол дня потерять чтобы потом за пять минут долететь"

У коллеги на примере heap и индекса для использования UPSERT это хорошо показано - да, апсерт классный и быстрый, но есть нюанс :)

Мне кажется тут тему все же нужно разбить на 2 части:

  1. Можно ли заставить BRIN работать на больших объёмах, коллеги показывают что у них не получилось, я предположил что сортировка может помочь, но это надо проверять. Если оно не работает - так и нет предмета для разговора.

  2. Допустим сортировка помогла, тогда мы имеем инструмент и нужно учится его грамотно применять, скажем в финальных витринах, или старых партициях, которые не меняются, т.е. там где количество select существенно превосходят количество insert. Ну и отдельная история запросы которые уже делают внутри неявную сортировку (например, group by). Но все это интересно лишь в том случае, если суметь заставить индекс работать.

по п2 согласен. Сортировка и для сжатия хорошо помогает

В целом понятно: Cloudberry быстрый, но на сложных операциях иногда тормозит, GP7 стабильнее, но тоже не без косяков. Если ещё на GP6, переходить стоит, но внимательно. Выбор есть, но лёгким он не будет.

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

Интересно. Спасибо. А можете поделиться временем выполнения q78.sql из TPC-DS для варианта scale=1000 ?

Для GP6 - 228c

Для GP7 - 186c

Для CBDB - 222c

Спасибо.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
glowbyteconsulting.com
Дата регистрации
Дата основания
2004
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
Снежана Шибаева