Beyond Joins and Indexes
My presentation "Explaining the Postgres Query Optimizer" covers the details of query optimization, optimizer statistics, joins, and indexes. This talk covers 40 other operations the optimizer can choose to handle complex queries, large data sets, and to enhance performance. These include merge append, gather, memoize, and hash aggregate. It explains their purpose and shows queries that can generate these operations.
This is a new talk; draft slides are at https://momjian.us/main/writings/pgsql/beyond.pdf
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
Christopher Travers Independent Community Member Principal Engineer
PostgreSQL vs Redis: Making the Right Choice
With the rise of NoSQL databases, a number of falsehoods have flourished regarding how to choose a database engine. This talk focuses specifically on Redis and PostgreSQL, and why one might choose one or the other.
At small scales, we can often get by thinking of database servers as black boxes, but as we scale, the internals and architecture become more and more important. This talk focuses on behavior of these systems at scale and under load.
In this presentation you will learn:
- How Redis and PostgreSQL differ architecturally
- How differences in architecture affect scalability and performance
- Cases here Redis is the clear winner
- Cases where PostgreSQL is the clear winner
Additionally, some notes will be offered in terms of where PostgreSQL can improve in to compete with the sorts of workloads that generally favor Redis.
-
Елена Скворцова ИТ-Экспертиза Руководитель направления технологической экспертизы
Миграция высоконагруженных решений 1С в инфраструктуру Linux/Postgres
Как перевести высоконагруженную информационную систему на платформе 1С:Предприятие из MS Windows/MS SQL Server на Linux/PostgreSQL так, чтобы не было мучительно больно?
Расскажем о стратегиях миграции и ключах к ее успеху. Делимся опытом в такого рода проектах, обращаем внимание на нюансы.
-
Максим Милютин Wildberries Разработчик/DBA
Аналитические open-source решения на базе PostgreSQL
Исторически PostgreSQL используется для транзакционной (OLTP) нагрузки. На это указывает строчное хранение данных и невозможность (или сложность) в организации распределённого исполнения запросов по канонам MPP (massive parallel processing) систем. Однако вследствие расширяемости ядра PostgreSQL (прежде всего, появления интерфейса подключаемых методов доступа) и либеральной лицензии (сходной с BSD) на свет появились различные форки и расширения, которые позволяют эффективно организовать обработку больших массивов данных для запросов аналитического толка.
В текущем докладе планируется дать исчерпывающий обзор форка Greenplum и расширений Citus и TimescaleDB с точки зрение разработчика по основным признакам (фичам) аналитических СУБД - колоночное хранение, сжатие данных, распределённая обработка и др. Результаты данного обзора будут полезны архитекторам, выбирающим СУБД для аналитики под свою систему.
-
Альфред Столяров ООО "Еваппс" (EvApps) директор
Как мы перевели клиента с Oracle на PostgreSQL до того, как это стало мейнстримом
Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.
В докладе расскажем, как нам удалось решить этот кейс.