title

text

March 15 – 17 , 2017

Postrelease

  • more than
    0 participants
  • 0 speakers
  • 0
    minutes of conversation
  • 63 talks
  • offline
    format

Talks

Talks archive

PgConf.Russia 2017
  • Michael Shurutov
    Michael Shurutov Postgres Professional

    1. What is an autonomous transaction?
    2. An overview of autonomous transactions in "big" DBMS: Oracle.
    3. Autonomous transaction logic in Postgres Pro.
    4. An overview of emulation methods for autonomous transactions in PostgreSQL.
    5. Comparing performance of the built-in Postgres Pro autonomous transaction mechanism and PostgreSQL emulation methods.

    VIDEO

  • Igor Chizhevskiy
    Igor Chizhevskiy SRC "Voshod"
    Sergey Korolev
    Sergey Korolev MCST
    Dmitry Pogibenko
    Dmitry Pogibenko FGBU "NII Voskhod"
    Stanislav Merzlyakov
    Stanislav Merzlyakov Scientific Research Institute "Voskhod"
    Илья Космодемьянский
    Илья Космодемьянский Data Egret
    Иван Богданов
    Иван Богданов SRC "Voshod"

    Practical experience of carrying out import substitution with using PostgreSQL in government information system including not only the free software, but also the Russian hardware (Elbrus servers and other).

    VIDEO

  • Marco Slot
    Marco Slot Citus Data

    Citus allows you to distribute postgres tables across many servers. It extends postgres to transparently delegate or parallelise work across a set of worker nodes, enabling you to scale out the CPU and memory available for queries.

    One year ago, we began a long journey to allow Citus to scale out another dimension: write throughput. With writes being routed through a single postgres node, write throughput in Citus was ultimately bottlenecked on the CPUs of a single node. Citus MX is a new edition of Citus which allows distributed tables to be used from from any of the nodes, enabling NoSQL-like write-scalability.

  • Radoslav Glinsky
    Radoslav Glinsky Skype (Microsoft)

    Do you test your PostgreSQL releases prior to Production in a dedicated test environment? Are you sure that your test environment (shortly Test) is equal to Production and in an appropriate state?

    In Skype we were facing multiple challenges associated with database testing:
    - Simplifying complex Production architecture of thousands of PostgreSQL instances, interconnected with RPCs and replications, infrastructure servers and external DB scripts, into their Test counterparts.
    - Constantly growing hardware requirements, insufficient cleanup of data generated in Test.
    - Differences between Test and Production were appearing and accumulating. Recognizing and fixing them required lots of effort.

All talks