AR
а индекс покажи
Size: a a a
2021 May 16
AR
хранит количество страниц
СА
CREATE INDEX table_name_surname ON public.table USING btree (name, surname)СА
У surname очень низкая селективность
СА
Я, разумеется, заменяю реальные названия полей и таблицы, из легкой паранойи.
AR
можешь попробовать:
- пересобрать статистику руками
- сделать order by во внешнем запросе, а where в подзапросе
но, кажется, у 11 посгри не очень со статистикой по мультиколоночным индексам
обнови pg )
- пересобрать статистику руками
- сделать order by во внешнем запросе, а where в подзапросе
но, кажется, у 11 посгри не очень со статистикой по мультиколоночным индексам
обнови pg )
СА
То есть если делать из этого кейс для учебника, то name и surname надо поменять местами. Но сейчас по факту surname вообще одно значение может иметь.
СА
> - сделать order by во внешнем запросе, а where в подзапросе
Это сломает исходный смысл: мне надо выбрать 10 последних Иванов в базе, а вообще Иванов в ней очень много, подзапрос вернёт огромный список.
Это сломает исходный смысл: мне надо выбрать 10 последних Иванов в базе, а вообще Иванов в ней очень много, подзапрос вернёт огромный список.
AR
не хочу тебя расстраивать, он и так вернет этот список
ДВ
А точно ли это баг? В индексе нет поля id -> он не учитывается в бинарном дереве, соответсвенно планировщик юзает тот индекс, по которому может отсортировать
СА
Хм, тоже верно.
ДВ
Кстати, ловилось, что индексы в 11 постгре в больших таблицах при частых вставках ломались и приходилось реиндексить самостоятельно.
СА
Спасибо!
AR
пофиксил?)
СА
Пока думаю, как лучше поступить. Может быть просто накину новый индекс name_surname_id и всегда буду добавлять surname в запрос.
СА
Так-то это edge case, когда нет записей с нужным name. Ещё варик - проверять сначала SELECT COUNT (*) WHERE name=$1, он мгновенно отвечает.
AR
Тебе же count не нужнен вроде? Тебе надо знать есть такое или нет. тогда лучше
SELECT EXISTS (SELECT FROM t WHERE name=$1)
IV
за что не люблю реляционные базы, так это из-за желания использовать одну структуру данных для всех use cases. В классическом мире реляционок индексы часто используются чтобы подпилить напильником структуру под условия задачи.
А должно быть наоборот - задача определяет структуру данных
А должно быть наоборот - задача определяет структуру данных
VG
я часто думал вьюхи делать для решения такой проблемы, но ни разу до них не дошел
IV
на серьёзных щах обсуждают как обмануть планировщик (aka black box). Камон, data redundancy это нормально