title

text

February 03 – 05 , 2016

PgConf.Russia 2016

Postrelease

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

Talks

Talks archive

PgConf.Russia 2016
  • Kamil Islamov
    Kamil Islamov Stickeroid Ai

    Method of automated refresh of preprocessed results of analytis reports is provided. Preprocessing and caching of reports allows ability for fast response for big data reports. Author describes the way of reports cache refreshing with minimum server loads and tuned actualization rate.

  • Fabio Telles Rodriguez
    Fabio Telles Rodriguez Timbira

    Challenges and solutions found in documents dematerialization and bank cheque processing system used in the Bank of Brazil.

  • Hyungjoo Lee
    Hyungjoo Lee Bitnine

    The Korean PostgreSQL User Group has been relatively small and inactive for many years. However, recently things are changing in Korea. Companies are seeking to alternatives for their expensive proprietary RDBMS in order to cut their TCO. And the government institutes also participate in this trend. We, Bitnine, are leading these changes in Korea. We launched the first version of our PostgreSQL solution, Agens SQL in 2015. We are translating the PostgreSQL documentation into Korean and operating the PostgreSQL User Group. And we are trying to contribute the PostgreSQL Global Development Group. Also, the first Korean PostgreSQL Conference will be hold in 2016. We will lead the organization of this conference. In this talk, we will present the current status of the Korean PostgreSQL User Group and the PostgreSQL DBMS market in Korea. And we also present our activities in Korea and introduce our successful migration cases of the proprietary RDBMS into PostgreSQL.

  • Andres  Freund
    Andres Freund Citus Data

    Postgresql's buffer manager has parts where it's showing its age. We'll discuss how it currently works, what problems there are, and what attempts are in progress to rectify its weaknesses.

    • Lookups in the buffer cache are expensive
    • The buffer mapping table is organized as a hash table, which makes efficient implementations of prefetching, write coalescing, dropping of cache contents hard
    • Relation extension scales badly
    • Cache replacement is inefficient
    • Cache replacement replaces the wrong buffers

All talks