title

text

Konstantin Evteev
Konstantin Evteev X5 FoodTech
11:00 05 February
45 мин

Standby in production

My talk will be about different cases of usage and setup of the standby server; examples how to setup standby linked to your archive( to make an opportunity to recreate standby from archive after primary crashing and promoting your old standby); Avito experience of usage of standby server for read-only queries: problems and solutions; monitoring of standby.

Слайды

Видео

Другие доклады

  • Joshua Drake
    Joshua Drake Command Prompt, Inc.
    180 мин

    Postgres Performance and Maintenance

    When you are optimizing Postgres it is usually maintenance that goes by the wayside. How do we fix autovacuum? Where did all of this bloat come from? Why am I getting IO spikes? How do I get RDS to behave?! Why are commits so slow on replication? The answer to all of these questions is understanding the relationship between proper Postgres maintenance and performance. Join us for a 3 hour jaunt through the wily world of making Postgres Go!

  • Irina Fast
    Irina Fast Сберобразование
    22 мин

    Differences between Oracle DB and PostgreSQL in terms of administrating

    As an experienced Oracle DBA, I've discovered some distinctive features of PostgreSQL which I'd like to share with you. We'll review a set of essential tools for DBAs, their capabilities and usefulness in comparison to their Oracle counterparts. Also I'm going to summarize the core differences between Oracle DB and PostgreSQL in terms of administrating.

  • Kamil Islamov
    Kamil Islamov Stickeroid Ai
    22 мин

    CTE Queries Usage for Business Logic

    Wide usage of Common Table Expression queries considered as a core paradigm for implementing the Business Logic for high loaded web applications development based on PostgreSQL functions.

  • T
    Tatsuro Yamada NTT Comware
    22 мин

    Auto plan tuning using feedback loop

    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:

    1. Automatic plan tuning by repeatedly feeding execution information to planner
    2. Preserve all plans generated during plan tuning in a history table
    3. 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)