Если в вашем коде TSQL много вложенных вызовов stored procedures, вы можете наглядно построить стек вызовов с помощью «flame chart» — стандартным представлением для профилирования вызовов.

Опишем по шагам всю процедуру.

Из ролика "Реальный собес на бекенд программиста": "А знаешь что-нибудь про горизонт событий транзакции? Знаю про чёрные дыры, а вот про транзакции не очень. Ну расскажи про чёрные дыры тогда. Вкратце."
По умолчанию утилита pgbench запускает тест "TPC-B (sort of)" и используется для быстрой оценки производительности PostgreSQL. Горизонт удерживается на время выполнения любого запроса или транзакции. В статье рассматривается насколько удержание горизонта базы данных (vacuum cleanup horizon) уменьшает прозводительность (например, значение tps тестов). Также приводится запрос для мониторинга горизонта баз данных и параметры, которые используются для защиты от долгих транзакций и запросов.

В статье описан алгоритм вакуумирования PostgreSQL и приводится сравнение числа сканирований индексов в 17 версии PostgreSQL и предыдущих версиях.

Есть пять фаз вакуумирования каждой таблицы, mwiew, toast и индексов на них: SCAN_HEAP,  VACUUM_INDEX,  VACUUM_HEAP,  INDEX_CLEANUP,  VACUUM TRUNCATE. Помимо них есть подготовительная фаза инициализации и завершающая фаза.

Клавиатура — пожалуй, главный инструмент ввода в современных компьютерах, который имеет множество параметров: размер, формат, профиль, подсветка, соединение, переключатели, материалы. Все они влияют на опыт использования — комфорт, быстроту печати, качество игры или работы.

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

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

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

Всем привет! Я Тимур, инженер в команде Databases Т-Банка. Занимаюсь решением проблем и настройкой производительности СУБД Oracle и PostgreSQL. 

По мере увеличения числа инстансов PostgreSQL оптимизация вычислительных ресурсов становится все более актуальной. Рассмотрим простую, но эффективную оптимизацию — prepared statements. В статье расскажу о некоторых особенностях custom и generic планов в PostgreSQL при выполнении prepared statements.

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

Если за последние три года у вас были крупные (или не очень) траты на покупку недвижимости, образование, медицину, спорт или просто есть дети, пришла пора обращаться за вычетом. 

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

Привет, Хабр! Меня зовут Глеб Типсин, я являюсь ведущим разработчиком продукта «Системы персонализации и геймификации» в SM Lab.

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

Материал подойдёт тем, кто только знакомится с мониторингом и хочет освоить «базу», а также тем, кто уже работает с Prometheus, но хочет "освежить" свои знания и узнать что-то новое.

Выбор SQL-запроса в реляционной СУБД в основном определяется пространством поиска возможных планов и техниками поиска плана в этом пространстве. У каждой СУБД оба этих фактора имеют свои особенности, что объясняет, почему иногда при миграции с одной СУБД на другую можно наблюдать как ускорения, так и провалы во времени выполнения отдельных запросов.

Здесь я привожу четыре случая, когда SQL Server позволяет строить планы запросов значительно более оптимальные, нежели это доступно PostgreSQL используя как более широкое пространство возможных планов, так и более совершенные методы оценок эффективности планов. Эти примеры: использование тредов, расширенная статистика, кэширование промежуточных результатов запроса и внутренняя параметризация. Примеры независимы и все кроме первого содержат скрипт воспроизведения - можно сразу листать на ту часть, которая выглядит интереснее.

Полагаю, знание о таких кейсах может быть полезным. Как минимум уменьшит количество стресса при миграции на PostgreSQL и возможно заинтересует кого-то настолько, чтобы начать свой проект в open-source сообществе разработчиков СУБД.

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

pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.

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

Опубликованный хронологический справочник содержит зарубежные литературные произведения научной фантастики, которые литературоведы и литературные критики относят к классике жанра. Хронология охватывает период со 160 года до 1 января 2025 года.

У нас не подгорит!

Как PostgreSQL хранит большие значения столбцов? Какие явные и неявные ограничения есть у существующего механизма хранения? Что за проблемы вызваны этими ограничениями? И как можно решить эти проблемы, и расширить возможности PostgreSQL? Об этом, и чуть больше - данная статья.

Мы успешно обновили кластер PostgreSQL с версии 13 до 16, обеспечив минимальный простой и высокую производительность. Процесс включал в себя создание новой реплики через логическую репликацию, перенос роли мастера на обновлённую реплику и настройку потоковой репликации. Несмотря на некоторые сложности, такие как управление LSN и проблемы с подписками, нам удалось сохранить данные и обеспечить синхронизацию.

Подробности читайте в статье.

Всем привет!

Продолжаем говорить о поступлении в Школу анализа данных Яндекса, а именно про подготовку по математике. Обсудим с чего начать, что входит в программу экзамена и какие бесплатные ресурсы помогут выстроить эффективную подготовку (в статье около 50 ссылок на книги/курсы), а в конце статьи поговорим про плюсы и минусы платной подготовки

Гоняем тесты кода на T-SQL в сборке каждого пулл-реквеста, собираем Coverage, проходим Quality Gate. Особенности построения CI-пайплайна для проектов БД MS SQL Server.

Тук-тук! Мы снова про IT Elements. На этот раз собрали видео и презентации с выступлений и удобно разбили их на треки. Смотрите и пересматривайте!

IT Elements 2024 объединила на одной площадке специалистов по ИТ-инфраструктуре, сетям и информационной безопасности.

Вот немного цифр:

→ более 2,5 тыс. участников офлайн
→ более 6 тыс. зрителей онлайн-трансляций
→ 125 спикеров
→ более 80 докладов, дискуссий и мастер-классов
→ 1 метрокластер на базе российских решений
→ 30 вендоров и дистрибьюторов
→ 4 зала: технологический, бизнес-, продуктовый и лабораторный

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

Я стал больше зарабатывать, чаще делаю то, чего действительно хочу, у меня хватает времени на себя и на то, что для меня важно и много чего ещё. В целом, жить стало интереснее.

В статье я поделюсь собственным опытом и опишу алгоритм, по которому я всё делал. Хорошая новость в том, что делается это всего один раз, постоянного ведения Икигай не требует. Если работа сделана тщательно, этот инструмент станет неким «светильником», освещающим путь впереди.

Один раз сделанная работа не значит, что вообще ничего и никогда переделывать и дорабатывать не нужно. Периодически всё же стоит заглядывать в то, что получилось, и подгонять под себя. Люди пластичны, мы приобретаем новый опыт, меняем ценности. Это и должно быть отражено в Икигай.

Прежде всего, добавь себе эту статью в закладки, потому что вряд ли у тебя получится сделать всё, что тут описано, сразу. А иметь под рукой короткое понятное руководство — это удобно. Да и поделиться с кем-то, кому такое тоже надо, будет проще.

Всем привет! Решил накидать книжных полезняшек для тех, кто любит DevOps или движется в этом направлении. Книги поделил по темам: сначала базовый уровень, потом архитектура, методологии, ну и всё остальное. В общем, от и до.

Я Сергей Задорожный, руководитель отдела платформенных решений банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки» от Яндекс Практикума. Раньше занимался написанием бэкендов на Java и Kotlin, потом занялся архитектурой, выстраиванием процессов, а сейчас заношу DevOps-практики в финтех-энтерпрайз.

Данная статья является продолжением: PostgreSQL 16. Страницы и версии строк. Часть 3.

В этой части мы поговорим о том, как ограничивается видимость транзакций с помощью снимков данных. Рассмотрим процесс создания снимков и их работу в условиях многоверсионности. Также мы обсудим понятие «горизонта транзакции» и процесс экспорта снимка данных.

Привет, Хабр!

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

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

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.