Настройка автопланировщика с использованием цикла обратной связи
As is often seen in OLAP and batch processing workloads, the more complex a query (containing many joins, filters, aggregates), the more there is a possibility of row count estimation errors, which leads to planner choosing an inefficient execution plan.
To address that problem, I developed a tool called pg_plan_advsr as a PostgreSQL extension, which corrects the estimation errors by repeatedly feeding back the information collected during query execution to the planner.
The tool has three features:
- Automatic plan tuning by repeatedly feeding execution information to planner
- Preserve all plans generated during plan tuning in a history table
- Create and store optimizer hints to be able to reproduce plans generated during tuning process
I verified the effectiveness of pg_plan_advsr by enabling it when running the join order benchmark (JOB) against PG 10.4 and observed its execution time shortening to 50% of the original. Therefore, it is useful for user who would like to do plan tuning for OLAP and batch processing.
I will talk about the following things in this presentation:
- Principles behind pg_plan_advsr and its architecture
- Detailed information about the measurements done with JOB
- Possible future enhancements
- Using aqo and pg_plan_advsr together (experimental)
Слайды
Видео
Другие доклады
-
45 мин
Andrey Borodin ЯндексDIY индекс
I'm going to talk about emerging technologies in the area of general purpose RDBMS indexing. I will describe different approaches suitable for different workloads. We will discuss ideas from academic researches and corresponding industrial response from developers, communities, and companies. There will be the short live-coding session on creating DIY index in PostgreSQL.
-
45 мин
Nikolay Samokhvalov Nombox LLCПромышленный подход к тюнингу PostgreSQL: эксперименты над базами данных
Shared_buffers = 25% – is it too much or not enough? Or it's the right value?
How can we ensure that this – pretty much outdated – recommendation suit well our needs?
It is time to start apply enterprise-level approach to tuning postgresql.conf. Not using various blind auto-tuners or advices from old articles and blog posts, but based on the following two aspects:
- comprehensive database experiments, conducted in automated fashion, repeated multiple times in conditions as close to production as possible, and
- deep understanding of DBMS and OS internals.
Using Nancy CLI (https://gitlab.com/postgres.ai/nancy) we will consider a concrete example: infamous shared_buffers, under various circumstances, in various projects. We will try to figure out, how to optimize this settings for given infrastructure, database, and workload.
-
45 мин
Julien RouhaudHypoPG 2: поддержка гипотетического секционирования в PostgreSQL
Declarative partitioning was a long-awaited feature and has been enhanced since its introduction in PostgreSQL 10. However, for many users, finding optimal partitioning schemes to have the best benefits from partitioning is not an easy task. Therefore, we added in HypoPG a new hypothetical partitioning feature which helps users to design partitioning. In this presentation, I will provide a brief introduction of HypoPG and explain declarative partitioning, and then I'll show the usage of hypothetical partitioning feature and explain how the extension is working.
-
22 мин
Artem Ivanov Atos IT S&S
Alexey Ignatov Postgres ProfessionalМиграция на СУБД PostgreSQL/Postgres Pro с многоядерными серверами Bull. Реальный опыт
To migrate to a PostgreSQL/Postgres Pro we need multi-core servers to be carefully tuned for correct parallelism. What settings make multi-terabyte installations work fast and correctly?
We will share our PostgreSQL/Postgres Pro on BullSequana S and Bullion S servers testing experience.
- The features of this hardware platform which are crucial for high-loaded configurations
- Multi-core Scale-up servers and PostgreSQL/Postgres Pro
- Results of stress testing of PostgreSQL/Postgres Pro running on the equipment.