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
  • Andreas Scherbaum
    Andreas Scherbaum Pivotal Ltd

    Greenplum is a PostgreSQL fork, optimized for Analytics and Data Warehouse use cases. Pivotal announced in early 2015 that a number of products will go Open Source, one of them is Greenplum Database. This talk provides an overview over the history of Greenplum, the entire process of bringing the product into Open Source, all the stumbling blocks we ran into, and explains how contributors can participate.

  • Jean-Paul Argudo
    Jean-Paul Argudo Dalibo

    The talk will be articulated around all the traditional arguments to "how chose PostgreSQL over other choices in the database domain"... But also, and that's quite new in the comunity, what are the consequences of this choice. Because the PostgreSQL adoption brings adoption of other things like Linux, but also, Open Source thinking, the fast pace of PostgreSQL will command new methods of validation the company must adapt to... etc.

  • Michael  Paquier
    Michael Paquier

    A backup is something that no Postgres deployments should go without as it gives the insurance to get back a deployment on its feet should a disaster strike.

    In this talk we will discuss why backups are essential in any sane PostgreSQL deployments (this seems obvious) and what are the different options available to define and set up a good backup strategy. On top of that is discussed how the future of backups would need to be handled, particularly regarding differential backups that gain in popularity among users with large deployments.

  • 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