Благодарю вас за такой прекрасный материал, чистое наслаждение слушать :) Если вы будете выкладывать информацию о докладчике под видео и прикладывать ссылки на его соц сети любить вас будут гораздо больше :)
Очень интересный доклад, больше года к сожалению приходится работать только с nosql elasticsearch и там структура данных при индексирование не b-tree а inverted index (array) что оптимизировано для поиска по тексту, кайфанул от просмотра, очень детально.
Насколько мне известно, при покрытии индекса (когда данные в таблице отсортированы) механизм индексирования не в таблицу заглядывает для определения видимости строк, а в так называемую карту видимости, в которой vacuum отмечает строки которые не менялись очень долгое время, и доступны всем транзакциям. И если идентификатор строки попадает в эту карту то видимость можно не проверять. Поправьте если не прав.
не понял про индекс по статусу и имени, не понял почему выгодно делать индекс статус-имя, ведь у статуса всего три значения и селективность у него будет явно хреновая, а вот у имени, особенно если именем будет какой-то никнейм, ну или даже имя человека, то там будет огромное количество разных значений у колонки и селективность будет явно больше, чем у статуса
это только для запросов, где мы ищем сразу по обоим полям всегда. С таким индексом, будет меньше случайных обращений, потому что мы загрузим один блок, где все state будут почти всегда одинаковые и мы разом прочитаем много нужных записей. Если искать только по полю name, то такой индекс считай бесполезен. Тогда действительно стоит создавать (name, state) индекс. Ну или создать рядом ещё один индекс только по полю name
В последнем примере про поиск по статусу и имени почему просто не создать частичный индекс куда войдут только строчки с PENDING если мы ищем только по таким строчкам?
Вот это да. 10 лет программирую, столько текстов прочитал о всякой-всячине, но конкретику нашел именно тут. Спасибо за видео
Что ж вы читали то? тутто как раз вода водой без конкретики
@@igorseledtsov7345а можете подсказать где подробнее всего описана работа индексов без воды? Хочу подробнее разобраться, непонятны некоторые моменты
@@igorseledtsov7345так это обычно нужно для вводной, а потом наложится что уже прочитанное
Очень полезный доклад. Побольше бы такого. Достаточно прикладные вещи, но мало где это подробно описано
Круто 👍 Очень полезно и без воды, спикеру отдельный респект 🫡
Прекрасный доклад
Спасибо!
Владимир, спасибо огромное за доклад!
Отличный доклад, большое спасибо автору 🙂
Шикарный доклад, посмотрел с удовольствием, хотя знал это всё)
отличный доклад, спасибо
Материал, презентация, доклад, все на высшем уровне, спасибо Владимиру за работу
Спикер - выше всех похвал. Спасибо большое, Владимир, было очень интересно!
Владимир, отличный доклад, спасибо!
Отличный доклад, спасибо !
Отличный доклад, спасибо!
Благодарю вас за такой прекрасный материал, чистое наслаждение слушать :) Если вы будете выкладывать информацию о докладчике под видео и прикладывать ссылки на его соц сети любить вас будут гораздо больше :)
Здравствуйте! Спикер оставил свои контакты в самом начале презентации 😊
Его ТГ @vladimirsitnikv, и электронная почта sitnikov.vladimir@gmail.com
Я только начинаю в PostgreSQL, мало что понял, но было интересно
Ситников - топ
Очень интересный доклад, больше года к сожалению приходится работать только с nosql elasticsearch и там структура данных при индексирование не b-tree а inverted index (array) что оптимизировано для поиска по тексту, кайфанул от просмотра, очень детально.
Шикарное объяснение
Очень доступно для новичков
Спасибо, отличный материал)
Хорошее объяснение. Буду шарить всем неверующим, что юид не самый лучший вариант для айдишки )))
Это не так. Есть такая штука как "последовательный uuid" и проблема со вставкой уходит.
@@nbukov дополню, сортировку поддерживают uuid v6 и v7
@@nbukov uuid v6
UUID нужен если необходимо шардирование базы данных. Если это не требуется, то и UUID использовать незачем.
Познавательно. Спасибо :)
огонь!!
последний вопрос явно был вопрос ради вопроса, что общего между дропом БД и индексами, да и вообще с постгресом?
Насколько мне известно, при покрытии индекса (когда данные в таблице отсортированы) механизм индексирования не в таблицу заглядывает для определения видимости строк, а в так называемую карту видимости, в которой vacuum отмечает строки которые не менялись очень долгое время, и доступны всем транзакциям. И если идентификатор строки попадает в эту карту то видимость можно не проверять. Поправьте если не прав.
Эта штука называется Visibility Map и да она для ускорения и там целый блок помечается битом содержит он данные старые или нет.
не понял про индекс по статусу и имени, не понял почему выгодно делать индекс статус-имя, ведь у статуса всего три значения и селективность у него будет явно хреновая, а вот у имени, особенно если именем будет какой-то никнейм, ну или даже имя человека, то там будет огромное количество разных значений у колонки и селективность будет явно больше, чем у статуса
это только для запросов, где мы ищем сразу по обоим полям всегда. С таким индексом, будет меньше случайных обращений, потому что мы загрузим один блок, где все state будут почти всегда одинаковые и мы разом прочитаем много нужных записей.
Если искать только по полю name, то такой индекс считай бесполезен. Тогда действительно стоит создавать (name, state) индекс. Ну или создать рядом ещё один индекс только по полю name
правильно ли я понял, что случайные uuid как индекс бесполезны и поск все равно будет перебором?
Нет. Речь была о скорости обновления индекса.
@@KikkerRusправильно ли я понял что при добавлении индекса с uuid, все индексы перестраиваются?
В последнем примере про поиск по статусу и имени почему просто не создать частичный индекс куда войдут только строчки с PENDING если мы ищем только по таким строчкам?
посмотрел
Отсортированный по времени UUID еще называют Ulid.
Это схожие, но разные виды id
Ни о чем, если честно.
Такая нуднятина, столько воды, жесть!
как раз таки не было даже капли воды, он за пол часа 100 страниц книги изложил
Очень корявая речь, как-будто к выступлению докладчик не готовился совсем. Местами утверждения некорректные из-за этого
Спасибо, отличный доклад. Штук 5 видео про индексы я посмотрела на ютубе, и только в этом услышала то, что помогло мне осознать суть происходящего.