Разбор задач викторины Postgres Pro на Highload++ 2017

[dovg]

Отличные вопросы.
Про Васю: ответ победителя — это ответ настоящего программиста. Как в том старом анекдоте про воздушный шар.

[tessio]

В 8-м задании получается, что функция будет вызвана всё же 2 раза, только на втором вызове она упадет.

[x-wao]

Ну нет. До вычисления функции дело не дойдет: ошибка возникнет при вычислении её аргумента.

[bolk]

Однако лишь один из победителей викторины заметил, что частичный индекс…

О, это был я, привет! На последней фотке как раз мне вручают билет. :)

[laz2]

Спасибо, интересно.

Однако лишь один из победителей викторины заметил, что частичный индекс

CREATE INDEX ON users ( somefield) WHERE lower(name) = ’vasya’;

где somefield — любое поле таблицы users, тоже окажется эффективен.

Не окажется. PostgreSQL не использует статистику для частичных-индексов, а это значит, что

SELECT * FROM users WHERE lower(name) = 'vasya';

будет планироваться с селективностью по умолчанию. См. рассылку

[x-wao]

Да, указанная проблема действительно есть! Однако из этого не следует, что индекс не будет использован. А если он будет использован, он может сильно помочь.

[laz2]

Да, вы правы, будет использован. Если я правильно понимаю PostgreSQL, то индекс будет использован практически всегда, так как селиктивность функции без статистики есть константа (вроде бы 1% или 5%). А это значит, что планировщик загнан в угол, даже если в таблице только 100 миллионов записей, подходящих под lower(name) = 'vasya'. Но в принципе такой индекс имеет право на жизнь, все-таки это пользователи…

[asvitin]

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

Конечно же, хорошо когда СУБД позволяет включить неиндексируемые поля в состав индекса (через INCLUDE), тем самым увеличивая возможности создания покрывающих индексов.
Но, строго говоря, это не обязательный атрибут «покрывающего» индекса.

[x-wao]

Отличное замечание, спасибо! Текст подправлен.