Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем:

-- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра;
-- Как GPLv2 помог найти эффективный алгоритм обхода соседей;
-- Как проиндексировали неиндексируемое гиперрёбра;
-- Планирование какого запроса смогли ускорить в 600 раз;
-- Какой изъян в работе существующего планировщика был найден.

Но главный сюжетный поворот — в конце...

Приветствую еще раз.

Это 2 часть небольшой статьи об отладчиках. В прошлой мы разобрали базу: инструкции + системные вызовы, написали свой отладчик, препарировали gdb и смотрели на отладку в высокоуровневых ЯП со своим рантаймом.

В этой мы посмотрим на процесс отладки в IDE изнутри, а потом пойдем еще глубже...

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

Вы когда нибудь отлаживали программы? Не врите, что нет. Благодаря отладчикам наши программы работают корректно (или хотя бы близко к этому).

Но вот знаете ли вы как отладка устроена: точки останова, шаги, бэктрейс, чтение переменных?

Нет или да - ответ не важен. Эта статья даст ответы на многие вопросы об отладке, которые вы, возможно, и не задавали себе.

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

Данные - это важный компонент системы. Приложение может хранить их где угодно, но в результате все сводится к файлам. Файлы - это хорошая абстракция, но она протекает: если не знать того, как работают ОС или гарантии файловой системы, то легко выстрелить себе в ногу.

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

Познакомил друга с понятием "Чистая архитектура" и он стал часто спрашивать меня как лучше сделать то или другое. Хотел дать ему к какому-нибудь туториал, но, к удивлению (плохому), не нашел подходящего.

Поэтому выкладываю небольшой обзор:

1.. Что такое чистая архитектура;
2.. Как можно реализовать;
3.. Мои мысли.

Целостность можно достичь различными способами. Например, чек-суммами. Вот как раз была такая задача - обеспечить целостность с помощью чек-сумм.

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

Но это простой путь слишком просто - так не интересно (да и лишних часов на таску надо тоже поставить). Поэтому решил усложнить себе жизнь разобраться в работе CRC!

Был отпуск и решил что-нибудь взять почитать. Наткнулся на книгу "Джоэл о программировании". Выбрал ее.

Изначально думал, что это самая обычная скучная книжка: написана на определенную тему, полно воды, много терминов и др. Спустя 2 главы свое мнение поменял. И вот почему.

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

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

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

Здесь описал свою реализацию и сделал сравнение с блокирующей реализацией.
Критика (даже не конструктивная) приветствуется.

Раньше IValueTaskSource был для меня загадкой, а правило не await'ить ValueTask несколько раз было для меня правилом, которому я слепо следовал.

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

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

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

У Uber - тысячи микросервисов. А у Netflix - несколько тысяч

В каком сервисе возникла ошибка? Сервис упал или просто ошибка сети? Что за ошибка возникла?

Стоп!
Рим не за один день был построен

Поэтому начнем с малого и подключим трейсинг к обычной микросервисной системе на ASP.NET Core.

Поможет нам в этом OpenTelemetry

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

Выбор между enum и собственным классом перечислений в C# был для меня сложной темой. Но когда увидел enum class из Kotlin, мое мировоззрение немного поменялось, я захотел иметь их в C#.

Но делать proposal мне не хотелось. И тут я вспомнил про генераторы исходного кода, добавленные в .NET 5, и решил, что пришло время их потрогать.

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

Продолжим погружение в код PostgreSQL. Сейчас посмотрим, что происходит, когда вы хотите выполнить запрос сложнее, чем в прошлый раз: добавим WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.

Плюс:

• Системный кэш

• Сходство обращения к столбцам и вызовов функций

• Предсказание количества возвращаемых кортежей

• Работа с простыми типами

• Маркировка столбцов при использовании FOR UPDATE

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

В этой статье рассмотрим какой путь проходит простой SELECT запрос. От стадии сырой строки до отправки ответа клиенту.

А еще:

• Работу со статистикой приложения через API Linux.

• Реализацию динамического списка.

• «Наследование» в C.

• Как ведется работа с диском в БД.

• Немного легаси.

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

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

Кроме нее будут рассмотрены:

— Модуль для работы с транзакциями.

— Исключения в С и их реализацию.

— Клиент‑серверный протокол.

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

На прошлом шаге мы дошли до входной точки Postgres. Сегодня мы пройдемся по ней до главного цикла. Будут рассмотрены:

— Модули для работы с файлами и файловой системой

— Как SIGUSR1передает множественные значения

— Реализации хэш‑таблиц

— Представление и хранение GUC

и многое другое.

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

Сегодня рассмотрим как происходит инициализация дочерних процессов после форка от Postmaster, некоторые системные вызовы Linux, goto, парсинг стартап пакета и многие хаки.

Приветствую

Появилась задача моделирования процесса теплопроводности. Для решения необходимо было использовать метод продольно-поперечной прогонки, а для распараллеливания - MPI

Разберем не только теорию, но и подробности решения

Продолжаем изучать исходный код PostgreSQL

В этот раз исследуем главный цикл сервера:

- Принятие входящих подключений;

- Проверка окружения;

- Обработка упавших воркеров.

Postgres - один из крупнейших open source проектов. Он создавался многие года. Кодовая база накопилась огромная. Мне, как программисту, всегда было интересно как он работает под капотом. Но не про SQL пойдет речь, а про язык на котором он написан. Про C. 

С общей архитектурой можно ознакомиться здесь

Для начала поймем, что происходит до входа в главный цикл сервера.

Всем привет!

Будем использовать GitHub Actions. Создадим виртуальную машину в Яндексе. И многое другое.

Сегодня настраиваем деплой из GitHub в Яндекс Облако, используя Docker compose.