pg укротитель

У разработчиков постоянно возникают проблемы при работе с базами данных. Они вызваны тем, что разработчики считают СУБД чёрным ящиком, который "просто работает" и даже не подозревают, что важно и нужно понимать не только стандарт SQL, но и подробности устройства конкретной СУБД.

Проекты разные, разработчики разные, но вот проблемы как правило одни и те же. Мы хотим продемонстрировать как разработчики пользуются базой данных и рассказать хорошо бы знать об устройстве СУБД, для того, чтобы писать код, который не разваливается как только компания из бодрого стартапа превращается в зрелый бизнес с планомерно растущими продажами и, соответственно, нагрузками.

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

Fuzzing-исследование PostgreSQL. Как мы искали и что мы нашли

Фаззинг-исследование, это когда мы подаем в программу (или ее часть) случайные входные данные (на самом деле случайность весьма условна) и смотрим что из этого получится. И так много раз на многих процессорах.

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

Исследование функций парсинга типов данных (input-функции): для разогрева;
Исследование функций реализующих операции между типами (op-функции): тут лучше учитывать структуру;
Фаззинг сетевой подсистемы: давайте притворимся, что мы POSIX-вызовы, так дешевле;
Восстановление дискового контекста: нужен день сурка.

Перепланирование безнадежных запросов в реальном времени

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

Механизм server-prepared statements в реализации PostgreSQL JDBC

Доклад о базовых принципах serever-prepared statements, и о фактической реализации в PostgreSQL JDBC. Планируется рассмотреть как базовые механизмы, так и краевые случаи.

Примерный список тем:

1) Как задействовать server-prepared statements
2) Какие настройки влияют на server-prepared
3) server-prepared vs batch execution
4) server-prepared vs concurrent executions (несолько разных подключений)
5) server-prepared vs connection poolers
6) Как понять, что server-prepared не работает
7) binary/text parameter/result encoding
8) server-prepared vs типы данных (грубо говоря, timestamptz vs timestamp vs text encoding)