Андрей Сальников - Индексы в PostgreSQL. Как понять, что создавать

[@esabkosabko4902]

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

[@jellyfish6265]

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

[@КимЧенОрк]

хахаха

[@MrElInfinito]

Материалы на pg pro+ книжка Рогова - все что нужно, дальше только практика. Уши завяли смотреть это «соплежевание» + бьющие в перепонки причмокивания.

[@vladislavkislitsyn8470]

@@MrElInfinito официальная документация - все что нужно, дальше только практика.

[@MrElInfinito]

@@vladislavkislitsyn8470 не согласен, ибо опытные люди делятся своими "бест практис", а читая чисто официалку и варясь в собственном соку можешь нарукожопить. Если работаешь с такими же практиками, регулярно обсуждая рабочие моменты...то да - можно чисто официалку читать.

[@РадикХисамутдинов]

Очень классный доклад, спасибо Андрею Сальникову за доклад!

[@mgsfdgsfdgsgssdgrsdgdrgsr16]

Отличный доклад, информативный, без воды. На 1.75 хорошо слушается.

[@sergeyz4591]

Без воды? Серьёзно? Там сплошная вода. Частичные индексы осваиваются за 2 минуты. Я всё надеялся что-то стоящее там увидеть, но увы! Более того, докладчик хорошо обосрался с порядком составных индексов.

[@mgsfdgsfdgsgssdgrsdgdrgsr16]

@@sergeyz4591 ну, если обосрался, то напиши в коментах, как правильно. Думаю, многие тебе будут признателтны.

[@gregoryrubies6045]

"Ты считаешь себя умнее базы данных?" - лучший ответ, по моему )

[@АлексейХудокормов]

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

[@hhh-sn2kj]

офигенный доклад. Спасибо!

[@alexanderyurlov8319]

Благодарю за доклад. Очень полезный.

[@eugenevodyanko4641]

Доклад, конечно, достойный. Но явно вводит в заблуждение пример с idx(created,state) - это эффективно будет работать только в частном случае распределения данных. В общем случае (и для разных СУБД), для реализации очереди или Top-N вариант с idx(state,created) будет гораздо более предсказуемым. Здесь явно не хватило подробных планов и сравнений. Кроме того, если таблица очень волотильная, то статистика может показывать «мультики», иногда ее следует отключить или «заморозить», чтобы оптимизатор не оптимизировал под «вчерашний день».

[@АлексейКузенков-г4и]

Доклад перевернул мое пониманик к тому, как надо создавать индексы🙏

[@Alex-qy5mh]

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

[@pick-pock]

Докладчик не очень быстрый, тк не хватает индекса

[@ИгорьКолесник-в3п]

)))

[@user-bl2zs2vt5s]

Спасибо, Андрей!

[@stanislavzemlyakov5442]

Максимально интересно.

[@oleg_shulga]

Спасибо за видео. Очень хороший доклад.

[@Narryel]

Крутой доклад, спасибо Андрею!

[@3dvfx1]

Андрей, Вас очень приятно слушать, Вы объясняете очень доходчиво, большое спасибо! 🤝

[@antonmuzeev]

Блин! Век живи, век учись! Буквально недавно прошёл курс от Postgres Pro по оптимизации запросов и смотря этот доклад, про себя думаю "Наверно мало чего нового узнаю"... А НЕТ! Очень крутой момент по индекс на ForeignKey. Я знал, что его нужно создавать, если планируется делать JOIN, но про кейс с удалением каскадом вообще не думал. За это огромное спасибо!

[@gennadyshevchenko7940]

видимо курс так себе?

[@andreymironov697]

Очень содержательно! Жаль, что Андрею не предоставили больше времени

[@maxx27i]

Спасибо за знания! Очень полезный доклад! 🔥

[@selub1058]

Спасибо. Классный доклад. 🎉

[@Mr43046721]

Очень классный доклад, Андрей прям гуру)) как и все чуваки из DataEgret

[@handletito]

Шикарное!!!

[@СергейС-с5т]

музыкальный инструмент на фоне - весьма нетонкий троллинг)))

[@Romerosmr]

Интересный разбор, только надо было всетаки по просьбе Владимира включить buffers в analyze. Тогда стало бы видно, что если первым полем в составном индексе сделать поле которое с критерием на равенство (статус), а вторым интервальный критерий (дату), то было бы меньше чтений блоков индекса, т к плотность нужных данных в листьях индекса была бы выше и соотв такой вариант эффективнее... и что ценно для ДБА - меньший IO

[@Nfix106]

Хороший доклад, спасибо!

[@greenbear8179]

прекрасный доклад

[@ВасилийГоловко-д9и]

Не понял немного пример по индексу, где мы создали по (дата, state). Если я захочу выбрать не обработанные транзакции по state, то индекс не будет работать. Чтобы работал мне надо в запросе использовать дату. А как я узнаю с какой даты у меня начинаются необработанные транзакции не используя для этого дополнительный запрос?

[@user-lv3hn6uz4e]

Почему сказано что VACUUM не чистит индексы? Это конечно можно отключить и он их реже чистит чем таблицу, но чистит и можно явно указать чтобы чистил всегда.

[@IlyaMatveev]

5:26, oltp голосом, на слайде опечатка (olpt) Online Transaction Processing

[@bit_happens_]

Спасибо!!!

[@danku3498]

Доклад интересный и полезный, спасибо! В целом со всеми моментами в видео согласен, но есть дополнение о котором не было сказано, нужно учитывать типы данных при его создании и текущий пример с фруктами можно было улучшить если сделать таблицу типов фруктов, ее id будет иметь маленький целый тип и индекс по двум прям будет значительно меньшего объема, а также чем меньше тип поля в индексе тем и объем меньше и стоимость его использования ниже..

[@jellyfish6265]

запили свое видео, посмотрим сколько будет просмотров

[@vladimir.kravets]

Если в исходном запросе (слайд 10) убрать limit, то разве перевернутая версия "от dba" будет адекватно работать? Мне кажется этот момент как-то очень не явно обозначен и, думаю, именно по этому вызвал много вопросов во время самого доклада. Тут ведь риск, что люди после доклада могут побежать переворачивать "как dba" там где надо и где не надо.

[@ogyct]

Многое не знал. Спасибо за доклад. Если честно, до сих пор не понимаю, в чем смысл индекса по ПК, ведь это всегда уникальные значения.

[@oleglevin7742]

Для поддержки уникальности нужна проверка, занято ли значение ПК, то есть выполняется поиск. А чтобы поиск был быстрым, нужен индекс.

[@ogyct]

@@oleglevin7742 а как индексирование ускорит поиск по уникальным величинам? Я всё время себе представлял индекс как из энциклопедий, где для одного слова выписаны страницы, где оно встерчается

[@ogyct]

хотя вроде уже понял, индекс это упорядоченный список, поэтому поиск по нему быстрее. Поправьте если ошибаюсь.

[@oleglevin7742]

​@@ogyct если говорить про b-деревья, на которых обычно строятся индексы, то принцип поиска и правда такой же, как бинарный поиск. Но структура - это, понятное дело, дерево :) То есть, оно состоит из узлов, каждый из которых хранит набор ключей и ссылки на дочерние узлы. Ключи в каждом узле отсортированы. Пара соседних ключей задает границы диапазона ключей дочернего узла. Применительно к базам данных рассмотрим два этапа: поиск ключа в узле и переход к следующему узлу. - Поиск ключа в узле быстрый, так как узел уже в оперативной памяти. Должно быть тут используется бинарный поиск. - Переход к дочернему узлу медленный, так как нужно читать с диска (если индекс не влез в оперативную память). Где-то видел, что обычно узлы хранят от 50 до 2000 ключей. То есть узлы крупные, зато дерево небольшое в высоту. Соответственно, количество чтений с диска сильно меньше, чем если бы использовались другие деревья поиска или просто упорядоченный список.

[@SARFEX]

Полезно ❤

[@riyazvagapov1449]

крутой доклад

[@user-007-1]

Не совсем понял - зачем создавать индекс на поле created_at, да ещё и ставить его первым? Мы же выбираем записи с совсем другим полем

[@pashk1ns]

Для кейса из презентации подходит пример из доки: Важный особый случай представляет ORDER BY в сочетании с LIMIT n: при явной сортировке системе потребуется обработать все данные, чтобы выбрать первые n строк, но при наличии индекса, соответствующего столбцам в ORDER BY, первые n строк можно получить сразу, не просматривая остальные вовсе.

[@Julia-nr8ne]

Мастер-класс по игнорированию просьбы включения buffers в план запроса😂

[@araikrasoyan702]

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

[@crazym8nd]

я как будто на лмампочку смотрел от этих флешбнгов на фоне

[@jellyfish6265]

охуенный доклад

[@MrAlexandrStv]

топчик

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

С одной стороны видно что есть весомый опыт, с другой какие-то заблуждения и суеверия. Называть индекс костылем это за колхоз и отсебятина? Давайте еще объявим костылем все алгоритмы сортировки с дополнительной памятью. Сортировка пузырьком вот единственно истинная сортировка.

[@outlaw4Iife]

постгресовый ведьмак

[@walcermelodia]

лол докладчик родственник олега тинькова?

[@Happy-s8l1c]

Лол, какие-то курсы по юмору проходил?

[@walcermelodia]

@@Happy-s8l1c лол а не пойти бы тебе лесом?)))

[@crypto-mech-arena]

Вот так наслушаешься этих горе докладчиков. И потом индексы не правильно работают. Индекс по двум полям будет работать, только по первому полю и обеим но не по второму.

[@crypto-mech-arena]

pg_stats показывает частоту вхождения только включенной настройке в конфиге.

[@ВасилийГоловко-д9и]

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

[@iuriigalchenko7673]

Только услышал от докладчика слово Ява, сразу отпало желание смотреть доклад😂😂😂

[@Antonio-ib6ii]

А зря

[@QWERTYQWERTY-ev2vr]

Кто от соера лайк

[@kaibrakhmanyelubay2671]

Человек который берет интервью неуважителен

[@ВасилийГоловко-д9и]

тоже это заметил, но его попустили, когда сказали, что он считает себя умнее postgress.

[@sobahuy]

этот человек один из коммитеров в jdbc postgres

[@ВасилийГоловко-д9и]

@@sobahuy и что это ему дает?

[@sergeyz4591]

Зато он задавал резонные вопросы. Если бы он их не задавал, то внимательные зрители не заметил тот факт, что докладчик в некоторых моментах обосрался.

[@gooldenboy666]

какое неуважение от интерьювера, это вообще шок

[@svfilipp]

Есть такой момент

[@22222222222222223464]

на 49:00 разве нахождение дубликатов в btree, которое внесли в 13 версию не сделает эту работу за нас?

[@twentxx]

Спасибо, Андрей! 👍