Владимир Ситников - B-tree индексы в базах данных на примере PostgreSQL

[@ВалерийЕрослаев]

Вот это да. 10 лет программирую, столько текстов прочитал о всякой-всячине, но конкретику нашел именно тут. Спасибо за видео

[@igorseledtsov7345]

Что ж вы читали то? тутто как раз вода водой без конкретики

[@pyramidhead9692]

​@@igorseledtsov7345а можете подсказать где подробнее всего описана работа индексов без воды? Хочу подробнее разобраться, непонятны некоторые моменты

[@DimaTiunov]

@@igorseledtsov7345так это обычно нужно для вводной, а потом наложится что уже прочитанное

[@gregoryrubies6045]

Очень полезный доклад. Побольше бы такого. Достаточно прикладные вещи, но мало где это подробно описано

[@UnitedIngvar]

Спикер - выше всех похвал. Спасибо большое, Владимир, было очень интересно!

[@РоманБойко-б1т]

Прекрасный доклад Спасибо!

[@АлексейТитаев-п6в]

Владимир, спасибо огромное за доклад!

[@romanlunin386]

Шикарный доклад, посмотрел с удовольствием, хотя знал это всё)

[@КонстантинМаксимов-п3о]

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

[@Serj1c]

отличный доклад, спасибо

[@adilkhanzaidulla8244]

Материал, презентация, доклад, все на высшем уровне, спасибо Владимиру за работу

[@MrVitalirapalis]

Очень интересный доклад, больше года к сожалению приходится работать только с nosql elasticsearch и там структура данных при индексирование не b-tree а inverted index (array) что оптимизировано для поиска по тексту, кайфанул от просмотра, очень детально.

[@RaptorT1V]

Я только начинаю в PostgreSQL, мало что понял, но было интересно

[@sergeng-gd5ev]

Владимир, отличный доклад, спасибо!

[@ДимаГоликов-с6ш]

Отличный доклад, спасибо!

[@vladglushak4306]

Отличный доклад, спасибо !

[@LarisaBogomolova-v1i]

Благодарю вас за такой прекрасный материал, чистое наслаждение слушать :) Если вы будете выкладывать информацию о докладчике под видео и прикладывать ссылки на его соц сети любить вас будут гораздо больше :)

[@Heisenbugconf]

Здравствуйте! Спикер оставил свои контакты в самом начале презентации 😊 Его ТГ @vladimirsitnikv, и электронная почта [e-mail]

[@Aleksey_P]

Очень доступно для новичков

[@coox4546]

Хорошее объяснение. Буду шарить всем неверующим, что юид не самый лучший вариант для айдишки )))

[@nikitabukov1292]

Это не так. Есть такая штука как "последовательный uuid" и проблема со вставкой уходит.

[@TheMrMagyar]

@@nikitabukov1292 дополню, сортировку поддерживают uuid v6 и v7

[@vasyavasin7364]

​@@nikitabukov1292 uuid v6

[@xfgweb]

UUID нужен если необходимо шардирование базы данных. Если это не требуется, то и UUID использовать незачем.

[@bobhutchinson3638]

Шикарное объяснение

[@TheNo0ker]

Ситников - топ

[@MarselPavuk-u6c]

Спасибо, отличный материал)

[@levorlov8788]

Познавательно. Спасибо :)

[@indigolight6007]

посмотрел

[@wickedtorpedo75]

последний вопрос явно был вопрос ради вопроса, что общего между дропом БД и индексами, да и вообще с постгресом?

[@kl45gp]

огонь!!

[@mcolegon]

Насколько мне известно, при покрытии индекса (когда данные в таблице отсортированы) механизм индексирования не в таблицу заглядывает для определения видимости строк, а в так называемую карту видимости, в которой vacuum отмечает строки которые не менялись очень долгое время, и доступны всем транзакциям. И если идентификатор строки попадает в эту карту то видимость можно не проверять. Поправьте если не прав.

[@amarazmable]

Эта штука называется Visibility Map и да она для ускорения и там целый блок помечается битом содержит он данные старые или нет.

[@sergeypoprygin2670]

не понял про индекс по статусу и имени, не понял почему выгодно делать индекс статус-имя, ведь у статуса всего три значения и селективность у него будет явно хреновая, а вот у имени, особенно если именем будет какой-то никнейм, ну или даже имя человека, то там будет огромное количество разных значений у колонки и селективность будет явно больше, чем у статуса

[@SergeyKomarov-k1k]

это только для запросов, где мы ищем сразу по обоим полям всегда. С таким индексом, будет меньше случайных обращений, потому что мы загрузим один блок, где все state будут почти всегда одинаковые и мы разом прочитаем много нужных записей. Если искать только по полю name, то такой индекс считай бесполезен. Тогда действительно стоит создавать (name, state) индекс. Ну или создать рядом ещё один индекс только по полю name

[@kvintnorris9828]

правильно ли я понял, что случайные uuid как индекс бесполезны и поск все равно будет перебором?

[@KikkerRus]

Нет. Речь была о скорости обновления индекса.

[@ivanmatew568]

Отсортированный по времени UUID еще называют Ulid.

[@PVBovercomes]

Это схожие, но разные виды id

[@aleona136]

В последнем примере про поиск по статусу и имени почему просто не создать частичный индекс куда войдут только строчки с PENDING если мы ищем только по таким строчкам?

[@mgsfdgsfdgsgssdgrsdgdrgsr16]

Ни о чем, если честно.

[@johnnester3115]

Такая нуднятина, столько воды, жесть!

[@wickedtorpedo75]

как раз таки не было даже капли воды, он за пол часа 100 страниц книги изложил

[@С.Семенчук]

Очень корявая речь, как-будто к выступлению докладчик не готовился совсем. Местами утверждения некорректные из-за этого

[@АленаБалаганская-ж7к]

Спасибо, отличный доклад. Штук 5 видео про индексы я посмотрела на ютубе, и только в этом услышала то, что помогло мне осознать суть происходящего.