Postgres 12 в этюдах / Олег Бартунов (Postgres Professional)

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
Saint HighLoad++ 2019
Тезисы и презентация:
www.highload.ru/spb/2019/abst...
Мой доклад будет состоять из нескольких мини-докладов, в которых я постараюсь рассказать про новую функциональность/улучшение/исправление и добавлю немного бэкграунда для лучшего понимания. Например, в 12 версии ожидаются поддержка KNN для SP-GiST и B-tree, но все ли знают или помнят, что такое SP-GiST и что такое KNN и как им пользоваться?
...
--------
Нашли ошибку в видео? Пишите нам на [e-mail]

[@KristinaMyLife]

Все таки Олегу Бартунову лучше выделить часа 1,5 на такой интересный доклад

[@victorm7551]

почему его торопят?!! ненавижу конфы, они постоянно не дают все рассказать! Где можно подробно послушать Олега?

[@SanSYS]

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

[@user-fh6xg9pn3y]

@@SanSYS Ага, тоже после выступления ловили его. Честно отвечает на все вопросы)

[@PostgresProfessional]

@mshigorin PGConf.Russia - так "слоновьи посиделки" по научному называются. Есть канал на KZbin: kzbin.info/door/6gJN4hEmnPHZ53HP2r7zhA Добро пожаловать.

[@dmitryd1572]

Отличный доклад, большое спасибо ! Изменений много и очень толково проведен обзор

[@ramajp]

Спасибо! Очень интересно и спасибо за ссылки на доп информацию.

[@ansarozden5767]

44:09 человек действительно любит своё дело

[@user-tb5fb6zm5j]

Молодцы ребята

[@AlexeyKamchatkin]

Олег Вы отличный докладчик! Молодец!

[@Xeningem]

38:48 "Все тут ошеломлены, да?"

[@sergeywhite8897]

Спасибо, скорее всего сам Олег этого не прочтет. Но все равно огромное спасибо!

[@RagazzoKZ]

Хорошая презентация

[@olegmakarikhin]

что за требование "на одной странице не меньше 4х записей". слышал про лимит "на одной странице не больше одной записи - это нормально"

[@igorm.9845]

Интересно, как внутри jsonb хранятся даты? Как строка или как дата?

[@AnatoleyTimchenko]

Кодзима гений, не иначе!

[@user-yj7je9ho4g]

когда уже репликация нормальная будет

[@vladimirblagin3105]

Появились JTP и PSS. Кто знает, что такое JTP и PSS? Мало знают. А это очень хорошая штука ...

[@mehpvm]

спасибо Тебе Йоко Оно :)

[@user-di7kt7bn3b]

про партиции всегда очень мало. Как уникальность контролировать в партиционированной таблице? Опять же осталась уникальность только в рамках партиции, что вообще не подходит никуда. Внешние ключи на партиционированную таблицу не сделать тоже.

[@GolubovAnton]

глобальных индексов нет что ли?

[@wovada]

Программирование развивается

[@AlekseiKazantcev]

А Украина нет

[@user-ey7rd9ih4g]

@@AlekseiKazantcev Входит неспеша в состав Российской Империи.

[@anatolyalekseev101]

У меня только один вопрос после просмотра этого видео: какого, извиняюсь, хера CTE до версии 12 не оптимизировались? Я их постоянно использовал вместо подзапросов по причине более элегантного вида, и думал, какой же всё ещё незрелый этот постгрес. Также, для меня партицирование можно назвать работающим, когда можно декларативно задать его по полю datetime, и, скажем, каждый месяц СУБД сможет создавать для таблици новый раздел. Иначе это сыро.

[@azamatgaliyev9931]

Это сын Джона и Йоко?

[@sergeik2151]

Оленевода😎

[@markusstainberg]

Говно мамонта этот постгрес, зачем его форсят?

[@kolchan11]

А что нужно форсить?

[@markusstainberg]

@@kolchan11 voltdb, clickhouse и подобные.

[@qaz261]

Пилят, пилят постгресс. А до сих пор проигрывает MS SQL по цене, по функционалу, по удобству мониторинга/настройки. Шумиха вокруг постгресса из-за молодых ИТишников, у которых своих мозгов нет, не могут обратиться к знанию/опыту стариков, но вот по конфам новомодным любят лазить. Олегу этому, в одной из конф в Новосибе, когда он про VODKA, Коньяк(не знаю на каком он хотел аббревиатуру сделать) задвигал, что придумал аббревиатуры, но не знает какой функционал под них запилить(кстати показатель уровня этого постгресса, что его гики создают чисто для прикола своего). Вобщем когда он заливал про производительность этой системы в сравнении с ms sql, задал вопрос за адекватность его сравнения, то он как-то мягко с темы съехал. Вобщем кто хочет наступить на грабли поддержки, получить большую цену продукта с неудобным интсрументарием, с поддержкой тормозной - берите постгресс. Слушай молодых балбесов, которые с универа пришли и задвигают "мы ща всё запустим враз, мы читали в инете". Кто хочет стабильности, возьмёт любой старый проверенный, отлаженный(математически доказанный) инструмент и сделает на нём решение удобное.

[@qaz261]

@@horserehab8454 "Любой", это под задачу подходящий, а не универсальная вундервафля, которая вроде всё может, но во всём проигрывает функционально заточенным. "Приведу пример. На одной конфе не рассказал, что постгре сделал монгу на джейсоне в синтетическом тесте. А на другой рассказал, что они допилили тест, чтобы распределение запросов было не линейное, а нормальное, что вроде как должно быть ближе к реальности и "все стало не так однозначно"... " Из сказанного(как математик по образованию), они сделали "упрощение" в задаче, допилили под неё реализацию и выкатили "доказательство" верности. Это ещё в школе(моей по крайне мере), нам рассказывали про сферического коня в вакууме. "Нормальное распределение" - это не есть "среднее житейское обычное". По бизнес процессам, по бизнес логике, от данных и работы с ними, строится как само хранилище(это собственно БД), так и настраивается доступ к нему с помощью СУБД(делаются запросы, строятся планы и т.д).... Взяв из горобки какую-то СУБД, раскатав на ней данные и начинать сравнивать со своей, которую оптимизируют для выигрыша над выбранной СУБД(из коробки прошу заметить), а потом говорить, что выйграли по тестам - это не спортивно как минимум и обман клиентов как максимум. Возвращаясь к вопросу "InnoDB?", то это хранилище. Это не СУБД. Тот же MySQl по дефолту использует это хранилище. Как MySQl выкупил Oracle и допилил, то очень даже нормальное хранилище для своих задач. Там кстати чёт вспоминается, что разрабов/решение InnoDB Oracle тоже скупило в своё время. Собственно к чему. В те времена, когда программист был не просто чувак шарящий в паттернах, бегающий по конфам и знающий все вновь возникшие "велосипеды", а был изначально математиком(в корочках высшего образования были вузы/факультеты математические). То эти люди прежде чем что-то делали - думали. Создавали мат-модели, алгоритмы имели математическое описание и в конце концов работа с данными, была описана математически. В результате возникали системы, которые за расчётное время делали работу заданную им. Люди ставили задачу на решение конкретной проблемы/задачи и её решали. Возвращаясь к Vodka.... кучка разрабов, в своё удовольствие херачат алгоритмы/решения.. "For Fun"... Линуксойды в большинстве своём такие же. Им не надо, чтобы было удобно, хорошо, просто. Им надо, чтобы было интересно. Как это скажется на пользователях? Решение которое сделано из кучи "веселух", для работы с которым надо нанять такого-же "весёлого"? В конечном итоге это поднимает стоимость внедрения/поддержки продукта.

[@qaz261]

@@horserehab8454 "функционал" - удобство работы. Нахера пользователям/разработчикам 100500 разных видов индексов, если тот же современный разработчик нифига не знает про двоичные деревья? Не знает как банальная qsort работает? Как наличие множества типов хранения/формирования индексов поможет в оптимизации решении на постгрессе? Ни как... Те кто внедрял этот "функционал" в постгресс, просто развлекался. Им было интересно это сделать. Интересно на синтетических тестах выиграть 0.00001% эффективности. Но пользователям не это надо. Им нужен удобный функционал, удобную гуйню, удобные системы мониторинга и отлавливания блокировок... Им нужно работать, а не изучать выкидыш фрикоф. Продукты Oracle и MS - хрен вытеснят такие решения... Только пока работодатели, закрывают глаза на эффективность работы разрабов... Только пока клиенты покупающие продукты с таким неудобным в поддержке функционале, не понимают и платят деньги - это живёт. Столкнулись с продуктом этим. Вынужденны были по требованию заказчика подготовить решения. Пока выкатывали, тестировали. Матерились. Тестировали, сравнивали. Кучу бабла выкатили для нанимания представителей постгресса, чтобы оптимизировать помогли решение. В результате, человек принятый на испытательный срок, в своё свободное время, сделал решение на СУБД "старом добром". По тестам нагрузочным - положило на лопатки решение после постгрессовских "спецов". Через полгода и клиент изучив тему, отменил требование по "импортозамещению". Постгресс - это поделка фриков.

[@qaz261]

@@horserehab8454 "геоданные", "адреса", "паспортные данные" - это просто данные. Я щас научу... Школа СССР - рулит. Да любая школа математическая из прошлого века рулит. Перед этапом проектирования хранилища, надо провести: 1) аналитику требований заказчика 2) выделить ключевые моменты и функционал 3) проговорит с заказчиком эти моменты, чтобы не облажать в бизнес-логике и бизнес-данных. 4) проработать данные 5) сформировать хранилище под данные и модель В результате "тип даных" - ну вообще похуй(извини за мой русский) становится. Это просто какая-то сущность. Если программист становится привязан к тому, что отсутствие поддержки какого-то типа данных в БД/СУБД тормозит его работу - это херовый программист. Херовый архитектор, если он БД проектирует. json в хранилище - вообще бред бредовый. Оферхед на хранение данных в 20 байт(структура из word и byte) , размазывается на 100байт... за это п*здить надо. Ладно хранение увеличивается... диск дёшев. Но эти данные надо ворочить в памяти и по сети гонять. геоданные.. широта/долгота.. два поля дабл. Какие могут быть проблемы в работе с ними? Зачем вводить новый тип? MS SQL и Oracle, вводя новые типы(те же геоданные и json/xml), просто идут в ногу с модой. Они не ломают свой функционал отлаженный, они не отнимают у пользователей удобство. Они просто поддерживают программистов новомодных(без знаний базиса) и не более. Без этого функционала можно работать успешно. А теперь давай собственно про "функционал" и "удобство", когда ты создаёшь продукт, продаёшь его клиенту у которого нет персонала прокачанного в гиковских темах и возникает проблема на площадке. Тут два решения: 1) выезд к клиенту за свой счёт(т.к клиент заплатил за продукт и всякие проблемы - это твои проблемы) 2) просить клиента самому создать отчёт по работе БД и выслать тебе на техподдержку(которая зачастую тоже не прокачана). Получаем, что первый вариант дорог и вытягивает из твоей конторы деньги. Второй варианты: 1) или давать клиенту "батник" чтобы он выполнил, создался лог и тебе прислал. Да клятвенно обещав, что ни какие корпортативные тайны/данные не выгребет этот скрипт. 2) или просить клиента выполнить типовые манипуляции в гуйне инструмента стороннего проверенного, который вернёт понятные данные, которые можно проверить по любому учебнику 90-х. Пострегрес неудобнен. Хз как ещё объяснить. Неудобнен в поддержке, не удобен в разворачивании, не удобен в профилировании, не удобен в продаже. В продаже особенно неудобен, когда всплывают дополнительные условия из-за которых цена продукта поднимается в разы.... та же работа на нескольких ядрах/процессорах. Ты рассуждать пытаешься как разработчик. Но ты не делаешь продукт для себя. Ты делаешь для рынка... И вот тут проблемы возникают из-за фриков... им не нужен рынок. Им и так хорошо. Они в консоле херачат 100500 команд по памяти, каждая с 1000+1 параметром и им это круто и удобно. Заказчик/рынок не оценит это.

[@realwhite_dev]

@@qaz261 Ну если вы не видите смысла в различных типах данных, то храните все в одном, делов - то. А консистентность данных проверяйте в приложении, ага. А потом придет Вася и ручками в бд добавит широту 120 и долготу -200... Ратуете за оптимизацию и быстродействие - сидите и занимайтесь байтоебством, а нам продукт выпускать надо =)) Если меня абсолютно устраивает оверхед по памяти и нагрузке на сеть, то почему я не могу использовать более удобные типы данных с точки зрения разработки? Мы пляшем от скорости разработки и простоты поддержки, это в большистве случаев гораздо больше заботит клиента чем цена на еще одну планку RAM. Вы, видимо, по умолчанию вопспринимаете любую инфраструктуру как кровавый ентерпрайз с ораклами, бигдатами, ActiveDirectory и прочими элементам огромной инфраструктуры. Где поддержка от вендора это главное (что бы было куда идти за помощью в случаях, когда своими силами нельзя решить проблему). Плавали в этом энтерпразном говне - знаем что это такое. Но так не у всех. Поэтому говорить “ваш инструмент говно, потому что у меня под него нет задач“ так себе затейка

[@alexeymorin2377]

MS SQL по цене... Вы наверное не знаете цены? MS использует просто заградительные тарифы, чтобы перевести всех в облака.