PostgreSQL *

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

Если вы стоите перед выбором между PostgreSQL и Oracle DB, то эта статья для вас. Разберем где PostgreSQL побеждает Oracle. Будет код и примеры — всё, что нужно для практического сравнения.

P.S: эта статья не про то, какой PSQL хороший в отличии от Oracle, а про то, в чем PSQL по мнению автора лучше.

Pandas — это основная библиотека для работы с данными. Вот несколько приёмов, которые я использую, чтобы быстрее и проще выполнять повторяющиеся задачи по работе с данными.

Приветствую! В этой статье поговорим про триггеры в PostgreSQL.

Начнём с базы: триггер в PostgreSQL — это такая функция, которая запускается автоматически при определённом событии в таблице. С триггерами можно автоматизировать массу рутины и освободить приложение от сложных проверок и вычислений, но это палка о двух концах.

Обе конференции - PGConf.СПб 2024 и PGConf.Academy 2024 - прошли в октябре. Они очень разные, но мы решили их объединить - может, как раз поэтому. Разница между ними не географическая. Даже наоборот, вышел парадокс: питерского уклона в составе докладчиков на PGConf.СПб 2024 в глаза не бросались, зато представители СПб (особенно представительницы) были более, чем заметны на московской образовательной конференции.

PGConf.СПб 2024

Прошла 1 октября. Однодневная, но в два потока уместила 18 докладов. Приятно, что открывал её доклад Павла Лузанова, а закрывал - доклад Егора Рогова - оба мои коллеги по Отделу Образования Postgres Professional.

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

В данной статье обсудим проблемы, возникающие при конкурентной работе с данными, а также инструменты для их решения – атомарные инструкции, явные и неявные блокировки и уровни изолированности транзакций, реализованные в OLTP СУБД PostgreSQL, MySQL, SQL Server, Oracle с примерами на Go. Поговорим о деталях их реализации в указанных СУБД. На примере PostgreSQL проведем benchmark-тестирование производительности уровней изоляции с использованием инструмента pgbench

В данной статье мы рассмотрим взаимодействие apache airflow, rabbitMQ и postgreSQL. Научимся правильно устанавливать соединения между ними и напишем базовый ETL.

Эта статья открывает цикл о новостях будущей, 18-ой, версии PostgreSQL. Рассмотрим следующие возможности попавшие в июльский коммитфест.

Планировщик: поддержка правого полусоединения хешированием
Планировщик: материализация внутреннего набора строк для соединения вложенными циклами в параллельном плане
Вспомогательные функции планировщика для generate_series
EXPLAIN (analyze): статистика рабочих процессов узла Parallel Bitmap Heap Scan
Функции min и max для составных типов
Имена параметров для функций regexp*
Режим отладки в pgbench
pg_get_backend_memory_contexts: столбец path вместо parent и новый столбец type
Функция pg_get_acl
pg_upgrade: оптимизация работы pg_dump
Предопределенная роль pg_signal_autovacuum_worker

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

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

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

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

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

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

Опять-двадцать пять, или резервное копирование баз данных PostgreSQL по новому. Снова.

В прошлой публикации мы обсудили механизм парсинга, оптимизации и исполнения запроса в PostgreSQL. В процессе обсуждения, был также затронут WAL (Write-Ahead Log). Давайте разберемся, что же это такое.

WAL, он же Write Ahead Log - бинарный лог, хранящий в бинарном виде непоcредственные результаты исполнения транзакций, модифицирующих текущее состояние данных. Речь идет о запросах INSERT, UPDATE и DELETE.

WAL обеспечивает Durability из ACID, т.е. сохранность данных в случае любых возможных сбоев.  Тем не менее, ошибочно представлять себе WAL как бэкап данных. Смысл данного механизма не в хранении копии всех созданных и измененных данных с момента создания бд.

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

MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!

Буквально месяц назад, мы с моим коллегой участвовали в HAKATON. Наша команда взялась за интересную задачу от компании МТС: на основе тысяч опросов, найти усредненный синоним к определенной категории ответов и визуализировать это в виде графика, либо облака слов.

После выполнения задачи и защиты проекта мы задумались...

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

Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.

Как известно, многие реляционные базы данных, а в данном конкретном случае PostgreSQL, обещают нам, что наши транзакции будут обладать соответствовать критериям ACID (Атомарность, Согласованность, Изолированность, Сохраняемость), при должном уровне конфигурирования тех или иных настроек.

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

А не будем мы о ней говорить прямо сейчас, потому что для начала хотелось бы поговорить о том, как в принципе выполняется запрос? Речь пойдет об одной машине Postgres, не рассматривая вопросы репликации и согласованности реплик.

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

Задача такая: искал Open Source БД для своего пет-проекта. Решил посмотреть в интернете новые решения в рамках БД. После чтения статей и отбора из 6-7 БД остались три (3), которые понравились лично мне. Больше ничего путного не нашел. 

Почему именно эти? Во-первых, они Open Source, а во-вторых, у них есть ответы на два главных моих вопроса «Для чего это нужно?» и «Работает ли из коробки?».

Давайте покажу на примерах.