Комментарии 13
А где кейсы и описание решения проблемы ?
время выполнения SQL-запросов для показателей хозяйственно-экономической деятельности клиента в PostgreSQL заметно больше, чем время выполнения тех же запросов для тех же показателей в Oracle. Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. И это несмотря на то, что база данных Oracle не была проиндексированной!
Хорошо бы увидеть планы выполнения в Oracle / MySQL и PostgreSQL .
Ну и ключевой вопрос - бизнес логика в PostgreSQL - где размещена ? А в Oracle ?
Статья и так набор малосвязанных фраз, а вы еще хотите про бизнес логику туда мусора добавить. Если писать про индексы, то причем тут логика? А вот про отличие хранения Null значений в index у ORAСДУ и PG вообще не упомянуто.
Если писать про индексы, то причем тут логика
Вот этот момент "Для «тяжелых» показателей разница во времени выполнения запроса могла достигать 20–30 минут. " очень интересный. Очень нужны детали и пруфы.
Ожидалось так - "вот смотрите план запроса в Oracle, вот план запроса в PostgreSQL, запросы одинаковые, данные одинаковые, инфраструктура одинаковая . Причина проблемы - ...... Но мы решили проблему , и вот каким образом ....."
А вот после этой фразы:
база данных Oracle не была проиндексированной!
Деталей технической реализации захотелось еще больше .
Я вообще полез это смотреть именно потому, что стало ну очень интересно, как можно индексировать именно базы данных, и что вообще имел в виду автор. Наткнулся на абсолютное пренебрежение хоть какой-то терминологией, убедился, что автор - аналитик, а не DBA... и тихо закрыл. Читать такое в понедельник с утра...
Откуда и когда в PostgreSQL появилась поддержка кластерных индексов?
Оператор CLUSTER указывает PostgreSQL кластеризовать таблицу, заданную параметром имя_таблицы, согласно индексу, заданному параметром имя_индекса. Указанный индекс уже должен быть определён в таблице имя_таблицы.
В результате кластеризации таблицы её содержимое физически переупорядочивается в зависимости от индекса. Кластеризация является одноразовой операцией: последующие изменения в таблице нарушают порядок кластеризации. Другими словами, система не пытается автоматически сохранять порядок новых или изменённых строк в соответствии с индексом. (Если такое желание возникает, можно периодически повторять кластеризацию, выполняя команду снова. Кроме того, если для заданной таблицы установить параметр FILLFACTOR меньше 100%, это может помочь сохранить порядок кластеризации при изменениях, так как изменяемые строки будут помещаться в ту же страницу, если в ней достаточно места.)
Когда таблица кластеризована, PostgreSQL запоминает, по какому именно индексу. Форма CLUSTER имя_таблицы повторно кластеризует таблицу по тому же индексу. Для установки индекса, который будет использоваться для будущих операций кластеризации, или очистки предыдущего значения можно также применить команду CLUSTER или формы SET WITHOUT CLUSTER команды ALTER TABLE.
CLUSTER без параметров повторно кластеризует все ранее кластеризованные таблицы в текущей базе данных, принадлежащие пользователю, вызывающему команду, или все такие таблицы, если её вызывает суперпользователь. Эту форму CLUSTER нельзя выполнять внутри блока транзакции.
В процессе кластеризации таблицы для неё запрашивается блокировка ACCESS EXCLUSIVE. Это препятствует выполнению всех других операций (чтению и записи) с таблицей до завершения CLUSTER.
Ну то есть к кластерным индексам это не имеет никакого отношения.
Прямо по пунктам:
всегда изменяет физический порядок хранимых данных
Нет, только при выполнении команды CLUSTER
Конечные листья индекса. Используются для хранения
Нет, индекс остается прежним.
Занимает много места
Нет. Занимаемое индексом место при операции CLIUSTER не изменяется.
Достаточно?
Индексирование баз данных в PostgreSQL: погружение в тему