Здравствуйте, а можно как-то сохранить explain из pgAdmin. Необходимо план запроса отправить разработчикам, а как его сохранить не понятно и есть ли вообще такая возможность?
@LudaMihko8 күн бұрын
Не понятно что в конце с is и is not?
@blackman85223 күн бұрын
Полностью согласен. Мне 21, работаю в ит в офисе, каждый день выхожу с офиса на полчаса походить по району.
@Dima-uz8giАй бұрын
Отличный урок! Огромное спасибо!
@user-tt9hx4kh1e2 ай бұрын
с самых азов учили наперед просчитывать все так, чтобы лишний раз не было никакой лишней нагрузки на систему
@leilailolo47362 ай бұрын
и зачем спрашивается тебе левый джойн, если ты в условии фильтруешь по этому полю из таблицы, котороую присоеденил, нужно было ставить обычный джойн, а условие писать в джойне, а не в where, что бы не создавать мегатаблицу
@lets_goto_it2 ай бұрын
Оптимизатор это давно хорошо отруливает
@sofiya41.2 ай бұрын
Здравствуйте, расскажите пожалуйста про хранимые пользовательские функции в постгрес🙏
@Seraf_2 ай бұрын
Просто СУБД не преисполнилась еще
@brainlesspolitican7432 ай бұрын
Слишком простые случаи вы рассматриваете) Помимо атомарности в acid еще 3 буквы. Но и помимо ACID, система транзакционности, это довольно глубокая тема, которая перетекает в mvcc , mvcc перетекает в изолированность и тд. Но документацию про доку соглашусь))
@user-xr2vl5wo7w3 ай бұрын
Это топовое объяснение🔥
@selub10583 ай бұрын
Круто ❤. Спасибо что делитесь опытом.
@crawner61983 ай бұрын
Очень полезное видео! Автор красавчик, все структурировано, понятно и голос приятный! Спасибо, помогли
@kura33274 ай бұрын
это goland что ли?)
@lets_goto_it4 ай бұрын
Pycharm или WebStorm, точно не помню (
@habib_sultan4 ай бұрын
Благодарим! Очень полезно основательно и без воды. Можно еще записать видос про лучшие практики по работе с большими БД (с подробным пояснением).
@lets_goto_it4 ай бұрын
Спасибо за поддержку! Хорошо, запишу в задачи для себя
@scum91804 ай бұрын
Что такое Seq Scan? Не повлияет ли новосозданный индекс на дальнейшую работу с таблицей? И не уволят ли с работы, если создать такой индекс 😂
@arturgspb4 ай бұрын
Seq scan - последовательное сканирование без использование индекса. Любой индекс надо тестировать на своих данных, так и обоснуете перед начальством и командой 😉
@wasabi_fox4 ай бұрын
спасибо!
@karinalazareva61235 ай бұрын
жаль, нет примеров с временными таблицами( например, в субд MS SQL - таблицы через #, ##
@karinalazareva61235 ай бұрын
@@lets_goto_it про TEMPORARY TABLE. cte и TEMPORARY TABLE есть отличия в контексте производительности?
@Chirickk5 ай бұрын
Опять не понял. Для чего мне вообще паковать все в контейнеры? Я так понимаю, это всё для молодых, кто в it недавно.
@lets_goto_it5 ай бұрын
Для всего свой инструмент, конечно. Одного правильного решения нет и пока не предвидится. При этом для большинства обычных проектов контейнеризация это, ИМХО, скорее благо. Если речь идет про сайты и подобное. А деплой по FTP скорее не благо. Для деплоя баз данных и подобного я бы сильно подумал из--за оверхедов на io диск,а например, но плюсы все равно будут, например для dev стендов. Всегда нужно смотреть на конкретную ситуацию и контекст.
@user-di4lm1dp9y5 ай бұрын
Все превосходно но бро, прошу убери звук на фоне. сильно мешает понять контент((
@lets_goto_it5 ай бұрын
Спасибо! Да, если такая проблема к сожалению и готовый видос не поправить к сожалению. ( В более свежих звука или нет или он оч тихо сделан. Может быть попозже сниму ремейк =)
@vakrokodil6 ай бұрын
спасибо!😊
@edmundslukasevics46236 ай бұрын
Спасибо, но пригодились бы таймкоды в видео :)
@lets_goto_it6 ай бұрын
Спасибо за комментарий 👍 Таймкоды там есть, но, видать низковато, поднял выше
@edmundslukasevics46236 ай бұрын
@@lets_goto_it аа, вижу в комментариях, в видео искал :)
@anniesunny83986 ай бұрын
Мемы - топ😂
@Vladimir_Posner6 ай бұрын
Polars мб лучше для джойнов
@lets_goto_it6 ай бұрын
В каких-то случаях, да, конечно. Одного правильного инструмента под всё никогда нет. Polars скорее всего может быть оправдан, если у вас датасайнс сложный и вам нужна гибкость или нет возможности подключиться к БД (или она под дикой нагрузкой) или делать join или группировку неэффективно. В обычных же случаях лично я предпочел бы простой join, группировку прямо в БД или ее реплике.
@Vladimir_Posner6 ай бұрын
Спасибо
@fedordostoevskiy42096 ай бұрын
Привет! Если есть возможность пробежать по литературе полезной.
@evgenievgeni20166 ай бұрын
А не кажется ли вам, что это борьба не с причиной, а со следствием? Зачем оставлять null в колонке? Чтобы что? Понятно, что цель показать частичный индекс, но пример не особо.
@binbinbinbin1236 ай бұрын
Просто, кратко, ясно и практично! Спасибо большое))) Первый раз за много лет пишу коммент в youtube)))
@uliavvvvvvvvvv6 ай бұрын
Большое спасибо за ваш курс,за ваш труд!Вас очень интересно слушать,а главное полезно)
@lets_goto_it6 ай бұрын
Спасибо 😊. Готовлю новые выпуски
@felakos15686 ай бұрын
Даже если ЯП разрешает "запивать водку пивом", я вежливо отказываюсь. Ну, вы меня поняли)
@felakos15686 ай бұрын
Бро, ты красавчик. Спасибо за помощь.
@yarik83men517 ай бұрын
Тоже работаю на удаленке, удобно, гуляю по 3 км после рабочего дня.
@lets_goto_it7 ай бұрын
Здорово! Если время позволяет, то это супер просто!
@fedordostoevskiy42097 ай бұрын
Это одно и тоже приложение-монолит на разных серверах или микро сервисы?
@gudjihn7 ай бұрын
Спасибо за видео! Но причём тут ссылка на Доку про copy?) Не делали explain своей вставки?) Как на уровне приложения изменить долгие строковые update на batchb update?
@lets_goto_it7 ай бұрын
Пожалста! COPY IN позволяет оч быстро потоково загружать данные в БД, COPY OUT оч быстро выгружать также потоково. Вы нашли в explain для этих методов что-то интересное? Про оптимизацию долдих апдейтов можно, кстати, видос записать отдельный - спасибо за идею! В целом обычно стратегия такая же как и с delete-ами, а именно - разбить группу строк на подгруппы и обновлять/удалять по отдельности пачками.
@eb60067 ай бұрын
Интересная вещь! Не знал про такое! Выглядит как класная идея!
@user-uu8hc9hj4c7 ай бұрын
1С можете покурить?
@lets_goto_it7 ай бұрын
Ну там совсем свой мир со своими инструментами и подходами, не подскажу, к сожалению, вообще
@user-ps4bt3vh9q8 ай бұрын
не прав насчет сравнениия тeхт и варчар есть разница.
@lets_goto_it8 ай бұрын
Вы зоркий глаз ;) Спасибо за комментарий. Да, она есть, но как по мне несущественная. Если строки у вас не будут конскими, то они не попадут в TOAST. В доке ( postgrespro.ru/docs/postgrespro/current/datatype-character ) написано "По быстродействию эти три типа практически не отличаются друг от друга, не считая большего размера хранения для типа с дополняющими пробелами и нескольких машинных операций для проверки длины при сохранении строк в столбце с ограниченной длиной. Хотя в некоторых СУБД тип character(n) работает быстрее других, в Postgres Pro это не так; на деле character(n) обычно оказывается медленнее остальных типов из-за большего размера данных и более медленной сортировки. В большинстве случаев вместо него лучше применять text или character varying."
@ibrahimoglu8 ай бұрын
👍
@passerist9 ай бұрын
Я плакал и ждал, когда автор нажмет Shif+F7, а так же увидит, что он выбирает всю таблицу, при этом ждет от слона использования индекса. лицорука
@lets_goto_it9 ай бұрын
Спасибо за ваш коммент, я проверил - все хорошо. Это просто стиль подачи информации - от оч плохого наивного решения с разбором почему не работает до поиска лучшего решения. Собственно ровно так, как и бывает у всех в жизни. Посмотрите до 18й минуты и вы увидите все заранее подготовленные патчи и запросы - я их использую для следующих итераций оптимизации с разбором того как все же заставить базу нормально выполнять всё.
@andreimikhalkevich56339 ай бұрын
спасибо автору, отличная подача информации, видео очень помогают в работе, переодически просматриваю, когда нужно оптимизировать или ускорить запросы
@TheDavBag10 ай бұрын
хотелось про эскплейн, конечно
@lets_goto_it10 ай бұрын
Как-то не сложилось у меня чтение в текстовом формате. Вы же про это? Если да, то для чего вам именно текстом? В pg admin есть пара кнопок для нормальной визуализации. Я тут только про одну рассказываю.
@TheDavBag9 ай бұрын
@@lets_goto_it хотелось про планировщик, почему индексы не всегда работают (процентаж выборки), про буферы, почему важно иметь кеш запросов, про характер выборки и первоначальную цель запроса, как с помощью EXPLAIN можно изменить понимание тог, что должен делать запрос. Даже простое объяснение отличия EXPLAIN от ANALYZE
@TheDavBag10 ай бұрын
прикольно, всякие "фишечки" типа ORDER BY в функциях не знал
@omg-go4vf10 ай бұрын
еще как я понимаю можно использовать inner join как средство фильтрации, то есть сокращения выборки для удешевления последующих фильтраций. Соответственно порядок inner join будет иметь значение. Я верно понимаю? комментарий в поддержку
@lets_goto_it10 ай бұрын
Да можно, но в отчетах как-то проблемы с ним часто возникают на реальных данных. LEFT join при отсутствии данных вернет null и вы этот null увидите и пойдете разбираться, в inner join срежет и всё =) Конечно, ситуации бывают разные, но опят показывает, что часто лучше себя показывает LEFT - так как если данные в порядке, то и все норм, а если не в порядке, то приложение упадет в худшем случае или, если вы знаете, что там может упасть, то запишете warning лог и будете обрабатывать следующую запись. Вот вам еще тру стори - всегда, когда у вас в приложении есть метод fetchOne, который должен вернуть одну строку или null, если ее нет, обязательно поставьте проверку, на случай, если вернулось больше одной строки и или падайте в том месте или пишите error лог, так как скорее всего что-то не так. Если подытожить - и left join и история с fetchOne призваны спасти вас от неправильной работы приложения / утере или порче данных.
@omg-go4vf10 ай бұрын
пример с json впечатляющий! Вы говорите что он накладный, а вот по сравнению с тем, как это будет делать python? как я понимаю, python помедленее будет...
@lets_goto_it10 ай бұрын
Все будет зависеть от того, что у вас еще на это БД выполняется. Питон очень легко горизонтально масштабировать под нагрузкой - запускаете еще pod-ов в Kubernetes с приложенькой и всё, а с БД так не пойдет. Т.е. надо смотреть характер нагрузки и общий тренд по использованию вашей БД, мб вам просто нужны асинхронная реплика БД для того, чтобы гонять там аналитические запросы на чтение - в этом случае это просто масштабируется и основное приложение вообще глючить не будет. В целом же я сторонник обрабатывать данные там, где они хранятся и поменьше выгребать в приложение. При этом если у вас БД будет не считать, а заниматься json encode / json decode все время, то тоже наверное ничего хорошего) Это не самая простая операция для PG, а еще хуже становиться, когда у вас JSON больше 2Kb - это вообще караул. Давно хочу про JSON и JSONB видос записать
@omg-go4vf10 ай бұрын
Возможно ранний вопрос, но не ясно как оценить расходы на запрос самой бд. Понятно что она быстрая и мощная и явно лучше написать сложный запрос, чем в питоне гонять из словаря в словарь, однако, все равно, не ясно. Вот например фильтр where created_at + interval '60 day' >= NOW() Кажется эта функция тяжелая на больших данных, так как надо делать много вычислений налету помимо остального. Как я понимаю функция которая делает выборку where created_at >= NOW() AND created_at < NOW() + INTERVAL'30 day' применяет вычисление лишь однажды и получает ответ значительно быстрее
@omg-go4vf10 ай бұрын
начну смотреть и конспектировать. Не так уж и просто было вас найти. Думаю отличный курс. За выходные справлюсь!
@Deletedeletedelete10 ай бұрын
какой операционкой ползуетесь?
@arturgspb10 ай бұрын
macos
@lets_goto_it10 ай бұрын
MacOs с 2013-го. Начинал в 2008 на Windows, потом было много разных линуксов, потом пересел на macos и она для меня вне конкуренции теперь. Там и красиво и нормальный терминал и это все же unix-овое семейство, что чуть упрощает некоторые дела. Есть много коллег, которые на Windows работают и у них тоже все норм, ра исключением того, что не все ПО нормально под windows работает, но конкретно у них все пучком уже. На серверах только linux
@Pacs31Ай бұрын
@@lets_goto_itwsl используется?
@Deletedeletedelete11 ай бұрын
Луна в третьем доме 1:06 Ахаххахах
@vladislavstepanov7591 Жыл бұрын
Еще можно было рассказать про отключение тригеров в базе, удаление индексов, удаление foreign связей на время копирования А после копирования вернуть в состояние как было Такое бывает нужно при миграции базы
@lets_goto_it Жыл бұрын
Спасибо! Вы все верно подметили. Бывает, что надо восстанавливать БД с отключенными триггерами, чтобы быстрее отработал pg_restore. Для этого у этой утилиты есть спец. параметр