В предыдущих статьях я рассказал об этапах выполнения запросов и о статистике.

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

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

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

Как обычно, я буду приводить примеры из демобазы. В этой статье будет довольно много планов выполнения, но про их составные части я буду рассказывать только в следующих статьях. Здесь же нас в первую очередь будут интересовать оценки количества строк (кардинальности), то есть числа, указанные в верхней строке плана в позиции rows.

Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы.

Предыдущие циклы были посвящены изоляции и многоверсионности, журналированию и блокировкам.

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

Материал перекликается с нашим учебным курсом QPT «Оптимизация запросов», но ограничивается только подробностями внутреннего устройства и не затрагивает оптимизацию как таковую. Кроме того, я ориентируюсь на еще не вышедшую версию PostgreSQL 14. А курс мы тоже скоро обновим (правда, на версию 13; приходится бежать со всех ног, чтобы только оставаться на месте).

Одна из вещей, которая связывает людей с работой их мечты — это резюме. Множество эйчаров смотрят на разные резюме каждый день. Если вы просмотрите хотя бы 10-40 резюме, то поймете, почему рекрутеры легко видят общие ошибки и насколько некоторые вещи выглядят для них забавно. Причем синьоры могут делать точно такие же ошибки, как и джуны, несмотря на то, что они уже 20 лет в индустрии.

Сегодня посмотрим на 5 резюме с точки зрения рекрутеров, которые ищут Python-разработчиков. На круглом столе конференции Python Week 2020 рекрутеры рассказали, что они ожидают от резюме по умолчанию, а что — им хотелось бы видеть еще. Два резюме будут от джунов, одно — от крепкого миддла, и еще пара — от кандидатов, которые решили поменять направление своей карьеры.

В прошлой части мы в общих чертах рассмотрели, как устроен REST API на DRF при работе на чтение. Едва ли не самый сложный для понимания этап — сериализация. Вооружившись исходным кодом, полностью разберем этот этап — от приема набора записей из модели до их преобразования в список словарей.

Важный момент: мы говорим о работе сериалайзера только на чтение, то есть когда он отдаёт пользователю информацию из базы данных (БД) сайта. О работе на запись, когда данные поступают извне и их надо сохранить в БД, расскажем в следующей статье.

Код учебного проекта, который используется в этой статье, доступен в репозитории на Гитхабе.

Про Песочницу API Тинькофф Инвестиции, которая ничего не знает про рынок. Это когда рыночная заявка исполняется по фиксированной цене, а лимитная исполняется сразу и по любой установленной цене. А заодно про незащищенный токен, про отсутствие Stop Loss / Take Profit в API. Недоумения пост...

В моей практике не раз были ситуации, когда хотелось посмотреть, какие именно запросы долго тупили в базе в определённый (конкретный) момент времени. А может, запросы не тупили, но каких-то запросов было слишком много.

Ключевое слово — в конкретный момент времени. Например, база непонятно от чего напряглась на 5 минут, потом всё само рассосалось, и очень хочется знать, почему. Отчёты за сутки, присылаемые dba на основе pg_stats_statements, не всегда проясняют ситуацию. Другие графики и логи могут помочь. Но всё же хочется не гадать на кофейной гуще, а конкретно посмотреть, что такому-то запросу в такое-то время было плохо, или его было много.

Можно, конечно, подключить системы а ля okmeter, но okmeter стоит денег. Да ещё и отсылает запросы в чужое облако — что, понятно, не в каждой организации можно считать безопасным.

На удивление, сделать такой мониторинг самому занимает всего полчаса времени, буквально с помощью нескольких строк Go-кода и палок.

Приветствую!

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

Статья о том как получить гринку через EPAM и похожий аутсорс. Сколько времени это займёт? Какие расходы оплачивает EPAM при переезде? Что такое L1 виза и как её получить? Что такое Green Card through employment.

Привет, Хабр! В этой статье я расскажу о том, как восстановить структуру таблицы и извлечь рукописные числа из отсканированного документа такого плана.

"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.

Minecraft — это не просто игра. Его используют в школах для развития детей, для воссоздания архитектурных объектов, улучшения безопасности на реальных улицах. Сегодня Cloud4Y поделится интересным способом запуска бесплатного сервера Minecraft в облаке.

С 5 июня 2021 года сайт гугла, и самое главное гугл таблицы - перестали отдавать данные с Московской биржи. 

При попытке получить любые котировки с префиксом MCX, например для Сбербанка, формулой из гугл таблиц =GOOGLEFINANCE("MCX:SBER") теперь всегда возвращается результат #N/A.

А при поиске любой российской бумаги на сайте Google находятся любые рынки, кроме Московской биржи.

В этой статье я рассказываю как получать в гугл таблицу биржевые данные с помощью API Московской биржи.

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

Я готовлю цикл статей, в которых расскажу о разных сторонах работы DRF. У меня пока нет значимого практического опыта для описания всех изюминок при работе с этим фреймворком, поэтому в основе статьи — исследование, обобщение и по возможности непротиворечивое изложение того, что у DRF под капотом.

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

Общую схему решения этой задачи мы рассмотрим в первой части статьи. Вторая будет посвящена детальному разбору процесса сериализации данных.

Телеграмм-бот для графического анализа опционов и фьючерсов с расчетом гарантийного обеспечения как меры риска.

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

А еще тут много про деньги.