o
Если говорить про OLTP
Size: a a a
2021 July 22
Д
Тенденция показывает что будет больше двух значений, но все равно очень мало для индекса 😂😂😂
RR
как тогда обойти fullscan?
o
В данном случае индекс вполне может помочь, если вам нужно найти быстро какой то редкий гендер. то на это редкое значение можно построить частичный индекс.
RR
допустим там 9999999 female и 2 male, и не хочется fullscan делать для where gender = male
o
выше уже написал, частичный индекс.
RR
так теперь допустим gender разных 100 штук, и будет запрос по всем видам gender, получается нужно сделать индекс для избежание full table scan, как тогда быть? частичный индекс в данном случае как я понимаю не работает, решение с партиций скорее сработает, но как сделать именно через индексы ? то есть что надо делать в постгре чтобы сделать что то типа bitmap индекс в оракле
БС
даже если будет 100 гендеров, попасть на seq scan - это не плохо.
o
какое распределение этих 100 значений? равномерное или же есть большие перекосы. Если какое значение будет больше ~20% (цифру точную не помню ) то поиск по нему будет дешевле сделать через full scann и даже если вы поcтроите индекс посгрес его не возмет.
o
Еще вопрос что у вас за запросы? сколько у вас данных в таблице, как много запросов?
БС
если в колонке гендера - 0 или 1, и на нем будет условный несуществующий битмап индекс, то планировщик постгре все равно будет выгоднее прочитать все, чем пытаться прочитать рандомное значение IO
RR
есть один 2 больших 45% 45% и остальные равномерно
o
тогда постройте частичный индекс для других значений "мелких" значений. по ним будет использоваться индекс, по этим 2-м большим будет фул скан, то так как он они очень часто встречаются то даже запрос с лимитом быстро вам вернет набор строк.
RR
хорошо звучит, спасибо за совет
o
Тут даже логически стоит вопрос а зачем нам фильтр который показывает только 45% от все таблице, если там 1 млн, 450 тыс. записей клиенту зачем?! он полюбому начнет применять дополнительные фильтры.
RR
почему планировщику выгоднее fullscan?
допустим у нас есть 2 гендера и на каждый гендер по миллион записей, мы делаем запрос где хотим заполучить 10 записей с гендер 1, когда постгре начнёт fullscan если окажется так что первый миллион записей который он прошел будет иметь гендер 0 тогда выходить что планировщику было бы выгоднее воспользоваться bitmap индексом
допустим у нас есть 2 гендера и на каждый гендер по миллион записей, мы делаем запрос где хотим заполучить 10 записей с гендер 1, когда постгре начнёт fullscan если окажется так что первый миллион записей который он прошел будет иметь гендер 0 тогда выходить что планировщику было бы выгоднее воспользоваться bitmap индексом
o
данные в БД не обязаны лежать упорядочено.
постгрес не гарантируют что данные будут читаться в таком же порядке что и были записаны.
постгрес может читать в несколько потоков.
поэтому ваша описанная ситуация маловероятна.
постгрес не гарантируют что данные будут читаться в таком же порядке что и были записаны.
постгрес может читать в несколько потоков.
поэтому ваша описанная ситуация маловероятна.
RR
да, я и не говорю что это часто бывает, мне интересно на оснований чего планировщик решает игнорировать, и привел контр пример
o
решает на основании статистики. есть pg_stats там расписаны свойства полей.
БС
ну воспользуется он bitmap, получит миллион данных с гендер 1. все равно это много. для него же вроде хорошо, если по индексу берет менее чем 20% данных. а не 50%. тут вопрос, откуда ограничение только на 10 запись. это ключ для запроса.
плюс, оверхед от битмапа большой. для каждой строки (2 млн), держать в памяти значение 0 и 1. а если еще и инсертить, апдейтить такую таблицу - таблица встанет колом.
плюс, оверхед от битмапа большой. для каждой строки (2 млн), держать в памяти значение 0 и 1. а если еще и инсертить, апдейтить такую таблицу - таблица встанет колом.