<?xml version='1.0' encoding='utf-8'?>
<schedule><version>Firefly</version><conference><title>FOSDEM PGDay 2019</title><start>2019-02-01</start><end>2019-02-03</end><days>3</days><baseurl>https://www.postgresql.eu/events/fosdem2019/schedule/</baseurl></conference><day date="2019-02-01"><room name="Other"><event id="2356"><start>08:30</start><duration>00:30</duration><room>Other</room><title>Registration</title><abstract /><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2356/</url><track>Breaks</track><persons /></event></room><room name="Hotel"><event id="2360"><start>09:00</start><duration>00:20</duration><room>Hotel</room><title>Welcome and opening</title><abstract /><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2360/</url><track>Hotel</track><persons><person id="1">Magnus Hagander</person></persons></event><event id="2287"><start>09:20</start><duration>00:50</duration><room>Hotel</room><title>Anonymization and Data Masking with PostgreSQL</title><abstract>Data anonymization is an old topic but with the rise of legal and ethical concerns about privacy, database administrators must keep track of senstive data and hide it to certain users in different contexts : unit testing platform, open data access, audits, development, etc.

This presentation is an overview of various anonymization techniques : substitution, randomization, variance, shuffling, encrypting, partial scrambling, ... with a  special focus on "dynamic masking".  These methods can now be implemented easily with  "PostgreSQL Anonymizer", an new extension that will hide or replace personal information using only SQL statements. 

This project is a prototype designed to show that data masking is key feature for Postgres. The long-term goal is to introduce a new specific DDL syntax for anonymization ("MASKED WITH ...") and let users define masks on certain columns, just like they would declare CHECK constraints.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2287/</url><track>Hotel</track><persons><person id="114">Damien Clochard</person></persons></event><event id="2307"><start>10:20</start><duration>00:50</duration><room>Hotel</room><title>Transparent Data Encryption in PostgreSQL and Integration with Key Management Services</title><abstract>Data encryption is one of the powerful methods to protect data from threats such as eavesdropping and theft.
It is essential when storing confidential information such as credit card numbers, personal information of users, etc.  Also, various data protection standards and regulations such as PCI DSS, GDPR, etc. require it.

There are various methods to encrypt data stored in PostgreSQL, such as pgcrypto and file system level data encryption using LUKS.
In practice, some security standards require database encryption to have the following four properties:

    * Transparent data encryption (TDE)
    * More robust and secure encryption key management while integrating key management systems (KMS)
    * Minimize performance degradation
    * Platform-independent

But our research tells us that there is no open source solution satisfying all four of them.
So we decided to both implement TDE on PostgreSQL and design it such that it integrates seamlessly with various KMSs. Our solution consists of per-tablespace database encryption. It encrypts and decrypts database data transparently to users by doing them at a layer between PostgreSQL's shared buffers and storages. We've tried to make sure that our implementation has minimum performance overhead.
Also, it can seamlessly store and fetch encryption keys by integrating with KMSs via KMIP protocol.

In this talk, we will first introduce some studies about TDE and KMS. Then, we will provide some internal details about implementing TDE and the details of integrating with KMSs.  Lastly, we will discuss our choice of design and a proof of concept explaining that.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2307/</url><track>Hotel</track><persons><person id="202">Masahiko Sawada</person><person id="571">Moon, Insung</person></persons></event></room><room name="Other"><event id="2357"><start>11:10</start><duration>00:20</duration><room>Other</room><title>Coffee</title><abstract /><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2357/</url><track>Breaks</track><persons /></event></room><room name="Hotel"><event id="2298"><start>11:30</start><duration>00:50</duration><room>Hotel</room><title>Parallelism in PostgreSQL 11</title><abstract>An overview of how parallel query execution works, with a look at some of the gory details that let you use multiple CPU cores for a single query in recent PostgreSQL releases. Topics covered include:

 * Industry context
 * PostgreSQL context and infrastructure
 * How parallel queries are planned
 * How parallel queries are executed
 * Practical examples, results and tuning
 * Problems to solve, opportunities for future work and related projects

The talk is aimed at application developers, DBAs and new PostgreSQL hackers who want to understand our model of parallelism, what kinds of problems it can help with and what's going on under the hood.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2298/</url><track>Hotel</track><persons><person id="574">Thomas Munro</person></persons></event><event id="2308"><start>12:30</start><duration>00:50</duration><room>Hotel</room><title>If the data do not come to R, then R must go to the data</title><abstract>Modern molecular biology produces experimental data in gigabyte and terabyte amounts that require statistical evaluation. Statistical packages such as R, SAS, certain Python and MatLab libraries allow for effective data analysis, but are typically suboptimal for data storage and management. Thus a common pipeline of data analysis would include uploading the data into a database, selection and manipulation on them in the database, writing the subsets into a text file, uploading the text file into a data analysis language of one’s choice and doing the statistical analysis there.
In this talk, I will show how large volumes of data can be analysed directly from the database using the PL/R PostgreSQL language extension. In particular, I will show how to use custom aggregate functions to pass lists of data values pre-selected in the database using certain parameters and perform statistical tests and real-time plotting using the R built-in functions. Since PL/R implements the full R functionality, it is also possible to use external libraries to produce print-ready plots. Nevertheless, passing several lists of values from the database to PL/R is still cumbersome, and I will show a work-around to do this.
Taken together, PL/R provides a powerful and extendable means to perform on-flight data analysis that avoids additional writing to disk and using multiple tools, and thus streamlines the data analysis and potentially makes it more efficient. However, there is probably still a long way to go before this combination of tools gains broad acceptance, and I will discuss some ways that we can make this happen.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2308/</url><track>Hotel</track><persons><person id="577">Olga Kalinina</person></persons></event></room><room name="Other"><event id="2358"><start>13:20</start><duration>01:00</duration><room>Other</room><title>Lunch</title><abstract /><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2358/</url><track>Breaks</track><persons /></event></room><room name="Hotel"><event id="2351"><start>14:20</start><duration>00:50</duration><room>Hotel</room><title>How not to screw up when building HA cluster</title><abstract>You just set up your first PostgreSQL cluster, created a database schema, loaded some data, did some fine tuning of configuration. Now you want to make your cluster highly available. Unfortunately, PostgreSQL doesn't offer built-in automatic failover, but luckily for us, there are plenty of external tools for that. As a next logical step you start choosing a tool, and... you already doing it wrong, because first you have to define SLA, RTO, and RPO. In this talk I am going to cover most of the common mistakes people do when setting up a highly available cluster.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2351/</url><track>Hotel</track><persons><person id="359">Alexander Kukushkin</person></persons></event><event id="2300"><start>15:20</start><duration>00:50</duration><room>Hotel</room><title>Security Best Practices Deep Dive</title><abstract>There are many aspects and considerations when securing PostgreSQL, with several examples of best practices embodied by compliance profiles such as the PostgreSQL STIG (USA) and the PostgreSQL CIS Benchmark (international). This talk will dive deep into some example best practices from those guides, giving the audience a sense for why these practices are prescribed, and how specifically to comply.

The audience is anyone interested in security within a relational database.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2300/</url><track>Hotel</track><persons><person id="38">Joe Conway</person></persons></event></room><room name="Other"><event id="2359"><start>16:10</start><duration>00:20</duration><room>Other</room><title>Tea</title><abstract /><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2359/</url><track>Breaks</track><persons /></event></room><room name="Hotel"><event id="2299"><start>16:30</start><duration>00:50</duration><room>Hotel</room><title>Periods and System Versioned Tables</title><abstract>SQL:2011 introduced the concept of a Period.  These can be used for many things but the most well-known application is system versioned tables where all changes to a table are recorded and can be summoned via SQL.

PostgreSQL is one of the last databases to implement this feature.  In this presentation we will see the many different ways periods can be used, and talk about the current status of their implementation.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2299/</url><track>Hotel</track><persons><person id="185">Vik Fearing</person></persons></event></room></day><day date="2019-02-03"><room name="Devroom"><event id="2274"><start>10:00</start><duration>00:50</duration><room>Devroom</room><title>Around the world with Postgres extensions</title><abstract>Postgres continues to get more and more feature rich. But equally as impressive is the network of extensions that are growing around Postgres. With the rich extension APIs you can now add advanced functionality to Postgres without having to fork the codebase or wait for the main PostgreSQL release cycle. In this talk we'll cover some of the basics of what an extension is and then take a tour through a variety of Postgres extensions including:

* pg_stat_statments
* PostGIS
* HyperLogLog and TopN
* Timescale
* pg_partman
* Citus
* Foreign data wrappers which are their own whole class</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2274/</url><track>Devroom</track><persons><person id="144">Craig Kerstiens</person></persons></event><event id="2282"><start>11:00</start><duration>00:50</duration><room>Devroom</room><title>Hacking PostgreSQL</title><abstract>This talk will include an introduction to the backend code and an example on hacking PG and adding in a new feature.  We'll cover what needs to be modified to add an option to an existing command (grammar, execution, etc) and the major components of PG (parser, commands, memory management, etc). We'll also cover the PG style guidelines, a crash-course on using git, how to submit your patch, and the review/commitfest process.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2282/</url><track>Devroom</track><persons><person id="84">Stephen Frost</person></persons></event><event id="2316"><start>12:00</start><duration>00:50</duration><room>Devroom</room><title>What's new in PostgreSQL 11</title><abstract>PostgreSQL 11 is out! Do you know what your favorite feature is yet? This talk will outline some of the bigger new features in this new version of PostgreSQL, giving you a chance to pick your favorite feature -- or to change your mind if you already had one!</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2316/</url><track>Devroom</track><persons><person id="1">Magnus Hagander</person></persons></event><event id="2321"><start>13:00</start><duration>00:50</duration><room>Devroom</room><title>Deploying PostgreSQL on Kubernetes</title><abstract>A look at some of the ways available to deploy Postgres in a Kubernetes cloud environment, either in small scale using simple configurations, or in larger scale using tools such as Helm charts and the Crunchy PostgreSQL Operator. A short introduction to Kubernetes will be given to explain the concepts involved, followed by examples from each deployment method and observations on the key differences.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2321/</url><track>Devroom</track><persons><person id="323">Jimmy Angelakos</person></persons></event><event id="2322"><start>14:00</start><duration>00:50</duration><room>Devroom</room><title>Breaking PostgreSQL at Scale</title><abstract>Database systems don't just slow down in a clear, linear way. They reach a certain point and start failing, often very suddenly and surprisingly.

This talk is about some of the most common scaling "discontinuities" in PostgreSQL, and how to plan for them and mitigate them. Why is SERIAL a bad primary key on high-insert-rate tables? What happens when autovacuum can't keep up? How do you know you don't have enough memory for your queries? What happens when a query that worked just fine before suddenly has a horrible plan?

Drawn from real-life examples, we'll go over these and show how to fix them… and avoid them in the first place.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2322/</url><track>Devroom</track><persons><person id="77">Christophe Pettus</person></persons></event><event id="2328"><start>15:00</start><duration>00:50</duration><room>Devroom</room><title>Data Modeling, Normalization and Denormalization</title><abstract>As a developer using PostgreSQL one of the most important tasks you have to deal with is modeling the database schema for your application. In order to achieve a solid design, it’s important to understand how the schema is then going to be used as well as the trade-offs it involves.

As Fred Brooks said: “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”

In this talk we're going to see practical normalisation examples and their benefits, and also review some anti-patterns and their typical PostgreSQL solutions, including Denormalization techniques thanks to advanced Data Types.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2328/</url><track>Devroom</track><persons><person id="14">Dimitri Fontaine</person></persons></event><event id="2346"><start>16:00</start><duration>00:50</duration><room>Devroom</room><title>Latest evolution of Linux IO stack, explained for database people</title><abstract>Input-output performance problems are on every day agenda for DBAs since databases exist. In Linux - probably the most popular operating system for databases now - there is a major overhaul of the IO stack for last several years. In this talk i will review what is going on there, why the IO stack needed an urgent improvement and what all those brand new NVMe driver and blk-mq layer improvements mean for databases, and database people. As a useful takeaway, I will provide a checklist of PostgreSQL and Linux settings to maximize IO performance with the new kernels.</abstract><url>https://www.postgresql.eu/events/fosdem2019/schedule/session/2346/</url><track>Devroom</track><persons><person id="88">Ilya Kosmodemiansky</person></persons></event></room></day></schedule>