<?xml version='1.0' encoding='utf-8'?>
<schedule><version>Firefly</version><conference><title>PGConf.EU 2019</title><start>2019-10-15</start><end>2019-10-18</end><days>4</days><baseurl>https://www.postgresql.eu/events/pgconfeu2019/schedule/</baseurl></conference><day date="2019-10-15"><room name="Other"><event id="2822"><start>08:15</start><duration>00:45</duration><room>Other</room><title>Registration</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2822/</url><track>Breaks</track><persons /></event></room><room name="Foscolo"><event id="2638"><start>09:00</start><duration>08:00</duration><room>Foscolo</room><title>The PostgreSQL Optimizer and indexes unleashed</title><abstract>The PostgreSQL optimizer is an important and sophisticated piece of software, which is often quoted but rarely understood.
Let us put and end to this and explain, what really goes on behind the scenes. You will learn about the PostgreSQL cost model, basic as well as more advanced optimizations. In addition to that indexes will be covered in depth. In many cases indexes are key to good performance and therefore it makes sense to deal with them in great detail to efficiently speed up your databases.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2638/</url><track>Training</track><persons><person id="39">Hans-Jürgen Schönig</person></persons></event></room><room name="Parini"><event id="2640"><start>09:00</start><duration>03:30</duration><room>Parini</room><title>PostgreSQL Security</title><abstract>Identifying database security breach points is the first step towards improving
your infrastructure so that you don't become a victim of malicious attack due to
preventable vulnerabilities.
This training course will show how to improve security on a PostgreSQL server in the
following areas:

* Operating System Security
* Network Security Strategy
* User Authentication Levels
* Schema Level Security
* Data Encryption
* Backup Security
* Row Level Security
* SCRAM authentication</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2640/</url><track>Training</track><persons><person id="541">Boriss Mejias</person></persons></event></room><room name="Porta"><event id="2637"><start>09:00</start><duration>08:00</duration><room>Porta</room><title>PostgreSQL Business Continuity</title><abstract>In this workshop we describe those PostgreSQL features that are most useful when
implementing High Availability as well as Disaster Recovery.
There are several third party solutions that might be used to assist the user in configuring
and managing PostgreSQL for those goals. However, we want to deliver a workshop which
appeals to a broad audience, irrespective of which tool they might be using already, or
planning to use.
We will therefore focus on understanding and using the actual PostgreSQL capabilities,
giving a comprehensive picture of replication and backup/recovery techniques, and how they
can be configured to achieve various degrees of Business Continuity.

We begin by introducing the Write-Ahead Log (WAL), and its applications to backup and
replication. Then we discuss how replication and backup/recovery are implemented, how
they can be configured to match specific requirements, and the activities required after going
live, such as monitoring, cluster management, and backup retention.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2637/</url><track>Training</track><persons><person id="34">Gianni Ciolli</person></persons></event></room><room name="Monti"><event id="2639"><start>09:00</start><duration>03:30</duration><room>Monti</room><title>Migration to PostgreSQL</title><abstract>Imagine you are requested to migrate a legacy database to PostgreSQL.
Just after the excitement generated by this announcement, you'll have to organize your work in order to both not miss a single point and your target to be reached.

Then you'll start the technical work:

  * Which questions would you ask whom?
    * Business context, workload
    * Dev: applications, stored procedures and functions
    * Ops: probes, system operations, lifecycle
  * How to organize your work?
    * Deadline
    * Primary study (data model, data, functional elements)
    * Details
    * Constraints
  * Which tool would you use to migrate?
    * Tools to migrate from Oracle
    * Tools to migrate from MySQL
    * Tools to migrate from SQLServer
  * Most common migration scenarios

In this training, you'll learn how to build your own migration workflow and get several tips with various well-known tools including `ora2pg`, `ora_migrator`,
`pg_chameleon`, `pgloader`, foreign data wrapper…

### Prerequisites:
  * For this training, trainees must have VirtualBox (at least 5.1) already installed and able to run virtual machines.
    VM images will be provided on a USB key.
  * Trainees should have an intermediate knowledge of PostgreSQL and of the source database (Oracle, MySQL, SQLServer).</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2639/</url><track>Training</track><persons><person id="469">Jean-Christophe Arnu</person><person id="676">Nicolas Lutic</person></persons></event></room><room name="Parini"><event id="2642"><start>13:30</start><duration>03:30</duration><room>Parini</room><title>The "default" postgresql.conf, step by step</title><abstract>If you ever wanted to find out what can be configured in postgresql.conf, you can easily find it in the official Postgres documentation. So, all you need to do is read it, yes, all of it, and you will have a perfectly configured database. Sounds easy, right?

The reality, however, tends to differ from the laboratory conditions that documentation describes, in addition, there is never enough time to go through the documentation, especially, considering that not every parameter would make sense for  your database. There are also settled differences that one should be aware of and the new releases that require constant adaptation of your config settings.

In this tutorial, I will take you through all the settings that, in my experience, as a consultant working with a variety of databases, should be adjusted. I will look into reasoning for it, and review the chain reaction that each change in each of these settings, will trigger. We will review some typical workloads and I will also be sharing some recommended configurations which our DBAs follow when setting up for our clients and which have been proven over and over with  different databases and under variety of our client’s requirements.

Following this tutorial you will have the knowledge required to understand major postgresql.conf parameters, know what role they play in the overall database performance and will be able to set up your own version that will work for your database.

If you are a DBA who is just starting to work with Postgres and would like to make sure that you have a reliable base to build your work on, this tutorial is for you.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2642/</url><track>Training</track><persons><person id="88">Ilya Kosmodemiansky</person></persons></event></room><room name="Monti"><event id="2641"><start>13:30</start><duration>03:30</duration><room>Monti</room><title>Implementing your first Postgres extension: from coding to distribution</title><abstract>One of the strongest features of any database is its extensibility and PostgreSQL comes with a rich extension API. It allows you to define new functions, types, and operators. It even allows you to modify some of its core parts like planner, executor or storage engine. You read it right, you can even change the behavior of PostgreSQL planner. How cool is that?

Such freedom in extensibility created strong extension community around PostgreSQL and made way for a vast amount of extensions such as pg_stat_statements, citus, postgresql-hll and many more.

In this tutorial, we will look at how you can create your own PostgreSQL extension. We will start with more common stuff like defining new functions and types but gradually explore less known parts of the PostgreSQL's extension API like C level hooks which lets you change the behavior of planner, executor and other core parts of the PostgreSQL. We will see how to code, debug, compile and test our extension. After that, we will also look into how to package and distribute our extension for other people to use.

To get the best benefit from the tutorial, C and SQL knowledge would be beneficial. Some knowledge on PostgreSQL internals would also be useful but we will cover the necessary details, so it is not necessary.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2641/</url><track>Training</track><persons><person id="393">Burak Yucesoy</person><person id="346">Onder Kalaci</person></persons></event></room></day><day date="2019-10-16"><room name="Other"><event id="2826"><start>08:30</start><duration>01:00</duration><room>Other</room><title>Registration</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2826/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2821"><start>09:30</start><duration>00:15</duration><room>Washington</room><title>Welcome and Opening</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2821/</url><track>PGConf.EU</track><persons><person id="78">Harald Armin Massa</person><person id="1">Magnus Hagander</person><person id="185">Vik Fearing</person></persons></event><event id="2559"><start>09:50</start><duration>00:50</duration><room>Washington</room><title>Safely Protect Your Passwords and Tell Others to SCRAM!</title><abstract>Passwords: they just seem to work. You connect to your PostgreSQL database and you are prompted for your password. You type in the correct character combination, and presto! you're in, safe and sound.

But what if I told you that all was not as it seemed, and there was a better way to authenticate with passwords in PostgreSQL?

PostgreSQL 10 introduced SCRAM (Salted Challenge Response Authentication Mechanism), introduced in RFC 5802, as a way to securely authenticate passwords. The SCRAM algorithm lets a client and server validate a password without ever sending the password, whether plaintext or a hashed form of it, to each other, using a series of cryptographic methods.

In this talk, we will look at:

- A history of the evolution of password storage and authentication in PostgreSQL
- How SCRAM works with a step-by-step deep dive into the algorithm
- SCRAM channel binding, which helps prevent MITM attacks during authentication
- How to safely set and modify your passwords, as well as how to upgrade to SCRAM-SHA-256 (which we will do live!)

At the end of this talk, you will understand how SCRAM works, how to ensure your PostgreSQL drivers supports it, how to upgrade your passwords to using SCRAM-SHA-256, and why you want to tell other PostgreSQL password mechanisms to SCRAM!</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2559/</url><track>General</track><persons><person id="6">Jonathan S. Katz</person></persons></event></room><room name="Manzoni"><event id="2569"><start>09:50</start><duration>00:50</duration><room>Manzoni</room><title>Performance analysis at full power</title><abstract>PostgreSQL is getting more and more mature, and used in bigger environments.
But at the same time, it's becoming more and more complex to administer as new
features and optimizations are added, and it's sometimes hard to diagnose
performance issues.  For example, access to operating system level metrics,
query usage statistics, and various information about internal events (like
waits or settings changes) used to be very hard to retrieve and analyze.
Fortunately, new performance metrics and statistic views are also regularly
added, either in the core or through third party extensions.

This talk will present several of these extensions, explaining what information
they give access to, and how they can be used to dig into bottleneck you can
experience in production.  The extensions this presentation will focus on are:

- pg_stat_statements (statistics on query usage)
- pg_stat_kcache (statistics on Disk / CPU usage)
- pg_wait_sampling (statistics on wait events)
- pg_qualstats (statistics on WHERE/JOIN clauses utilization by queries)
- pg_track_settings (track configuration changes)
- hypopg (hypothetical indexes)

In addition, PoWA will be presented as an example of combining them and exploit
their power to the full.  This is a tool that regularly stores the metrics
provided by those extensions in a space efficient format, and a web application
that can represent all the gathered metrics on different dashboards with a
drill-down approach, and which can also automatically analyze the data to
suggest optimizations, such as missing indexes.  But each extension, and
others, can of course be used independently to do performance analysis.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2569/</url><track>DBA</track><persons><person id="132">Julien Rouhaud</person></persons></event></room><room name="Foscolo"><event id="2709"><start>09:50</start><duration>00:50</duration><room>Foscolo</room><title>In Aid of RTFM</title><abstract>A discussion of ways to improve the documentation ecosystem for PostgreSQL inside core, other sources and help in citing those sources in outside forums.

The documentation for PostgreSQL is quite extensive, but that can work against us when attempting to cite a specific feature or function. We are left with telling information-seekers here's a link to a very long page, look for the $SEARCH_TERM in that page. Some users seem to learn best when first given a concrete example of the usage of a command or feature, and only then will the abstract documentation make sense.

This talk proposes a number of incremental changes that could improve the usability and durability of our documentation in both core and the ancillary wikis. Such as examples with date/version context, flagging new features, and persistent reference anchors. It will also propose some standards for citation of sources when making references to them in outside forums like StackExchange.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2709/</url><track>General</track><persons><person id="409">Corey Huinker</person></persons></event></room><room name="Washington"><event id="2557"><start>10:50</start><duration>00:50</duration><room>Washington</room><title>Everything About PostGIS</title><abstract>The [PostGIS](https://postgis.net) spatial extension to PostgreSQL includes over 300 functions for managing and analyzing spatial functions. This talk will cover all the features of PostGIS, small and large, obscure and well-known, new and old. 3D, curves, spatial referencing, indexes (GiST, BRIN, and SPGIST), spherical and cartesian data, raster data, topological structures, clustering, triangulation, linear referencing, data validity, the DE9IM, and even more! If you know what PostGIS is in general, but want to know the full range of things it can do, this is the talk for you.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2557/</url><track>General</track><persons><person id="478">Paul Ramsey</person></persons></event></room><room name="Manzoni"><event id="2589"><start>10:50</start><duration>00:50</duration><room>Manzoni</room><title>Meet NULL the UNKNOWN</title><abstract>Of course, you know everything you need to know about NULL, don't you ? 

NULL and three-valued logic are often misunderstood and can induce poor written queries, wrong written queries (when the result is not as expected) and a lot of time lost trying to figure out what your missing colleague wanted to do with such a tricky and bad-twisted SQL code.

After defining NULL and UNKWON (and you'll see that it's not so simple), we'll go through different use cases where 3-valued logic is used, what pit you don't want to fall into and how you can improve query writing, now that you fully understand what's behind NULL in PostgreSQL.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2589/</url><track>Developer</track><persons><person id="387">Lætitia AVROT</person></persons></event></room><room name="Foscolo"><event id="2679"><start>10:50</start><duration>00:50</duration><room>Foscolo</room><title>Fibonacci Spirals and 21 Ways to Contribute to Postgres—Beyond Code</title><abstract>Postgres is growing like gangbusters: in popularity, in adoption, and in the size of the ecosystem. And over 400 developers contribute code to Postgres today: their expertise, design chops, and skill are big factors in the increasing popularity of Postgres. But what if you’re not a developer? Are there things you can do to help grow the usage and popularity of Postgres? And are these non-code ways to contribute to Postgres important? Valued? Will they make a real difference? 

If you love Postgres and want to help drive Fibonacci growth of the Postgres community, this talk is for you. I’ll walk through 21 different (and important) ways to contribute to Postgres—along with tips and resources for getting started.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2679/</url><track>General</track><persons><person id="535">Claire Giordano</person></persons></event></room><room name="Parini"><event id="2797"><start>10:50</start><duration>00:50</duration><room>Parini</room><title>How many CPUs for 60000 TPS</title><abstract>I have done some interesting research on the relationship between the number of CPU's and the TPS that is achievable. This is the results of that research. A lot of Graphs show some very interesting details on The number of concurrent connections, the number of CPU's the impact of SSD (vs tmpfs), fsync=off, etc. and a lot of other comparisons.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2797/</url><track>Sponsors</track><persons><person id="642">Sebastiaan Alexander  Mannem</person></persons></event></room><room name="Other"><event id="2811"><start>11:40</start><duration>00:20</duration><room>Other</room><title>Coffee</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2811/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2571"><start>12:00</start><duration>00:50</duration><room>Washington</room><title>Be Inclusive: Welcome Non-key Columns in B-Tree Indexes</title><abstract>PostgreSQL 11 introduced the INCLUDE clause for b-tree indexes. The main intention of this clause is to enable Index Only Scans without including selected columns into the index key. But the INCLUDE clause has many other interesting capabilities that might be even more useful than the support of Index Only Scans.

This talk gives you a brief introduction into b-tree indexes, Index Only Scans and what the INCLUDE clause does. It demonstrates where cases the INCLUDE clause can be beneficial and discusses a few more subtle benefits that are not commonly known. Finally, the talk also shows the limits of the INCLUDE clause in PostgreSQL 11.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2571/</url><track>Developer</track><persons><person id="142">Markus Winand</person></persons></event></room><room name="Manzoni"><event id="2691"><start>12:00</start><duration>00:50</duration><room>Manzoni</room><title>Barman in action</title><abstract>Barman has recently added interesting features for managing backups and the recovery of PostgreSQL instances. Let's look at some of the most common ways to configure Barman with PostgreSQL and secure your data, until zero data loss is achieved.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2691/</url><track>DBA</track><persons><person id="4">Gabriele Bartolini</person></persons></event></room><room name="Foscolo"><event id="2714"><start>12:00</start><duration>00:50</duration><room>Foscolo</room><title>Marketing Postgres brand - where to start?</title><abstract>Over the years, PostgreSQL developed organically - the improvements and the new features have been added by the companies as a result of specific client’s needs, bringing the database to the state as we know it today.

Though the popularity of PostgreSQL brand has, so far, grown without dedicated efforts to popularize it, I suggest, that now is a good time to tap into some marketing techniques to strengthen its positioning among other open-source solutions and accelerate its buy in. In fact, by exploring conversations about Postgres, we might be able to identify some unaddressed issues and understand the wider community interests that in turn can influence how we, as a community, talk about Postgres and how the database will evolve.

In this talk, I will share some ideas on how communication surrounding Postgres influences the database and the community. I will also give an overview of social media channels where Postgres conversations are taking place and will present the analysis of relevant Twitter conversations.

My aim is to raise questions rather than dictate answers and bring the discussion about marketing Postgres, as the world's most advanced open source database, to the table, where the results of the analysis could serve as a guide for PostgreSQL activities and its messaging.

This talk is for everyone who cares about PostgreSQL and its community and also for those who are interested in understanding the big picture, learning about marketing and social listening and understanding how today’s communication may influence the future of PostgreSQL.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2714/</url><track>General</track><persons><person id="657">Valeria  Kaplan</person></persons></event></room><room name="Parini"><event id="2664"><start>12:00</start><duration>00:50</duration><room>Parini</room><title>PostgreSQL under Windows</title><abstract>Beginning from the 8.0 version PostgreSQL had native support for Windows. However there are still a lot of questions and misunderstandings.

In this talk I'll tell about history and features implemented. Will show how to build and install PostgreSQL from the sources, how to build extensions, if they are not available in binary form. Will describe differences in tuning cluster under Linux and Windows.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2664/</url><track>Sponsors</track><persons><person id="72">Pavlo Golub</person></persons></event></room><room name="Washington"><event id="2555"><start>13:00</start><duration>00:50</duration><room>Washington</room><title>Jsonpath in examples and its roadmap.</title><abstract>PostgreSQL 12  introduced a jsonpath - the query language for json, which is an important part of SQL/JSON specification in SQL-2016 standard.  Jsonpath is a flexible way to specify the parts of json  to be used for processing in functions and operators.  The language being very rich  is quite complex and we will demonstrate how it works using examples from simple to complex quieries. Also, we will explain how indexes works for jsonpath and show the performance benefits of using jsonpath and old arrow operators.

We will present  the roadmap for PostgreSQL 13 and further releases.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2555/</url><track>General</track><persons><person id="504">Nikita Glukhov</person><person id="164">Oleg Bartunov</person></persons></event></room><room name="Manzoni"><event id="2594"><start>13:00</start><duration>00:50</duration><room>Manzoni</room><title>Beyond the pushdowns – distributed query planning and execution</title><abstract>Nowadays, it's generally agreed that community way to sharding is combination of partitioning and foreign data wrappers (FDW).  Naturally, one could turn a local database to distributed one by moving some data partitions to foreign servers.

A lot of efforts were spent to provide FDW a bunch of query optimization techniques including pushdowns of aggregates, joins and orderings.  These optimizations allow to making more computations locally.  That in turn improves scalability of query processing.

However, pushdowns are not enough for real scalability of OLAP queries, which requires complex processing of large amounts of data.  Such queries requires so-called "re-partition", runtime redistribution of data between cluster nodes.

In this talk we present our work on distributed query planning/execution.  It provides full-fledged OLAP query optimization including "re-partition".  Our distributed query planner and executor require only few core modification, while being built in pluggable way using hooks and custom nodes.  The efficiency of proposed approach will be shown on both syntactical and real-life benchmarks.

While being essential part of sharding, we hope distributed planner/executor will become part of community sharding roadmap.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2594/</url><track>Internals</track><persons><person id="64">Alexander Korotkov</person></persons></event></room><room name="Foscolo"><event id="2520"><start>13:00</start><duration>00:50</duration><room>Foscolo</room><title>A Deep Dive into PostgreSQL Indexing</title><abstract>Indexes are a basic feature of relational databases, and  PostgreSQL offers a rich collection of options to developers and designers. To take advantage of these fully, users need to understand the basic concept of indexes, to be able to compare the different index types and how they apply to different application scenarios. Only then can you make an informed decision about your database index strategy and design. 
One thing is for sure: not all indexes are appropriate for all circumstances, and using a ‘wrong’ index can have the opposite effect to that you intend and problems might only surface once in production. Armed with more advanced knowledge, you can avoid this worst case scenario!
We’ll take a look on how to use pg_stat_statment to find opportunities for adding indexes to your database. We’ll take a look at when to add an index, and when adding an index is unlikely to result in a good solution. 
So should you add an index to every column? Come and discover why this strategy is rarely recommended as we take a deep dive into PostgreSQL indexing.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2520/</url><track>General</track><persons><person id="608">Ibrar Ahmed</person></persons></event></room><room name="Parini"><event id="2824"><start>13:00</start><duration>00:50</duration><room>Parini</room><title>From full-time onsite DBA to remote expertise. A journey in effective PostgreSQL support</title><abstract>With bigger adoption of PostgreSQL worldwide, the needs for expertise has increased.
However, newcomers wouldn’t accept the idea of having a bad start, or worse, having to turn back to the old technology, because of lack of PostgreSQL expertise.
What’s more the increased need for high profiles enforces the idea of a lack of candidates.

How can we prevent the adoption of PostgreSQL to be stopped by the apparent impossibility to find expertise? 
We can, for instance, wonder if enterprises do really need a full time expert on-site. It is actually possible to work with experts outside the enterprise.

Referring to our consultancy experience, we will show during this talk that a project may be successful despite the expert not being full time on-site.
We will also discuss solutions to help teams successfully increase their PostgreSQL skills while the lack of PostgreSQL candidates is a reality.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2824/</url><track>Sponsors</track><persons><person id="66">Stéphane Schildknecht</person></persons></event></room><room name="Other"><event id="2812"><start>13:50</start><duration>00:50</duration><room>Other</room><title>Lunch</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2812/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2608"><start>14:40</start><duration>00:50</duration><room>Washington</room><title>25 Interesting features of PostgreSQL 12</title><abstract>PostgreSQL continued to be the DBMS of the year for 2018. An interesting fact is that there is a new release every year. So we have another new release this year, PostgreSQL 12. It is planned to be released in the third quarter of the year 2019. There are a lot of improvements in partitioning, query planner, Indexing and some SQL features, etc. Among all of the interesting features for developers and admins, we shall be discussing 25 of them in 50 mins with some examples and benchmarks done on the PostgreSQL 12 beta 1.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2608/</url><track>General</track><persons><person id="578">Jobin Augustine</person></persons></event></room><room name="Manzoni"><event id="2748"><start>14:40</start><duration>00:50</duration><room>Manzoni</room><title>The present and future of vacuum and autovacuum</title><abstract>In this talk we will have a look at the details of vacuum/autovacuum's implementation and see what kind of practical implications they have. The talk will also provide an overview of patches for vacuum and autovacuum that are currently being considered by the developer community and that may be included in newer versions of PostgreSQL.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2748/</url><track>Developer</track><persons><person id="650">Akenteva Anna</person></persons></event></room><room name="Foscolo"><event id="2541"><start>14:40</start><duration>00:50</duration><room>Foscolo</room><title>Caching long running queries</title><abstract>There are various approaches to cache query results using various algorithms, such as generic LeastRecentlyUsed and TimeExpiry algorithms, generic low level caching with deltas (Nagata), or high level entity caching architecture using logical decoding (Atanasovski). 
Our time stamp deltas based approach sits between the low level algorithms and the high level architectural solution. It is developed to address a situation in our document storage system, where 
- the use of the queries is too irregular and often sporadic (ruling out LRU or TE)
- no IDs are present
- the system is not write intensive ( eg. 0-4 entries per second per relevance set)
- the queries are complex
- time stamp is a part of the query</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2541/</url><track>Developer</track><persons><person id="617">Laszlo Forro</person></persons></event></room><room name="Parini"><event id="2830"><start>14:40</start><duration>00:50</duration><room>Parini</room><title>nbtree-indexes in PostgreSQL. Useful novelties.</title><abstract>nbtree-indexes exists in PostgreSQL for decades, this is the default and the most commonly used index type. In the upcoming 12th version there will be significant changes to the way these indexes work.
We'll start with a small insight into the way nbtree indexes work in general: internal structures, basic operations, as well as problematic areas that exists and show up from time to time (yes, we're speaking about bloat).
Next, we'll see what had been done for the 12th version of PostgreSQL (expected to be released during the fall) and also what are the possibilities for future improvements.
Finally, some words on how to use indexes, how to "disable" index, and also on how to use multicolumn indexes.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2830/</url><track>Sponsors</track><persons><person id="425">Victor Yegorov</person></persons></event></room><room name="Washington"><event id="2623"><start>15:40</start><duration>00:50</duration><room>Washington</room><title>PostgreSQL's IO subsystem: Problems, Workarounds, Solutions</title><abstract>PostgreSQL's IO subsystem—while working well for a large fraction of installations—has a few problems:

- hard to predict latency, especially on databases that are significantly larger than the available memory
- IO throughput, especially with fast storage subsystems (e.g. NVMe SSDs), is not high enough
- backends perform too much write IO themselves, as the background writer does not work very well
- unnecessary random write IO is generated (bgwriter, backends)
- double buffering between kernel page cache and postgres' shared buffers
- all read IO is synchronous (from the OS page cache) 
- large shared_buffers can cause problems when tables are very frequently dropped or truncated
- ...

After an introduction of how PostgreSQL's IO subsystem works, the above problems (and maybe some workarounds), the talk will go over current work to improve this situation.  This work includes:

- new background writer (patch in a decent prototype shape)
- new buffer mapping implementation, enabling new optimizations (patch in early prototype stage, potential improvements include fast DROP/TRUNCATE, write coalescing, better readahead)
- direct IO</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2623/</url><track>Internals</track><persons><person id="140">Andres Freund</person></persons></event></room><room name="Manzoni"><event id="2586"><start>15:40</start><duration>00:50</duration><room>Manzoni</room><title>Good data gone bad, bad data gone worse</title><abstract>How bad data gets into the pipeline, how developers make data bad and worse in the pipeline. This talk will look at data sources, data types, and ways postgres can be used to abuse data.

I bring my experience doing QA for a startup to discuss problems we've seen in many data sources, as well as how we found and addressed those data quality issues. Additionally, I will talk about some of the things that a user can do or not do in postgres that might or will definitely lead to data corruption.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2586/</url><track>General</track><persons><person id="588">Renee Huinker</person></persons></event></room><room name="Foscolo"><event id="2671"><start>15:40</start><duration>00:50</duration><room>Foscolo</room><title>Data Compression in PostgreSQL and its future</title><abstract>There are few data compression features available in PostgreSQL today, but the community is currently developing data compression features that can be used in a variety of situations, including improvements to TOAST, columnar compression, and communication data compression. In this talk, I will share some of the compression features under development in the community and talk about future of data compression in PostgreSQL.

Also, I will present the page-based table compression for OLTP environments that we are working on, which compresses the data using a compression method that leverages the page items and places it in the cache. The purpose of this implementation is to reduce storage costs in OLTP with minimal overhead. I will talk about the structure and other details of the function, including the result of the performance evaluation.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2671/</url><track>Developer</track><persons><person id="648">Iwata Aya</person></persons></event></room><room name="Parini"><event id="2833"><start>15:40</start><duration>00:50</duration><room>Parini</room><title>Migrating to PostgreSQL</title><abstract>- Why migrate to PostgreSQL.
- Planning your migration.
- Migrating business logic.
- Converting data types.
- Migrating SQL - function, procedures, triggers, and more.
- Typical challenges encountered and how to handle them.
- Post-migration tests.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2833/</url><track>Sponsors</track><persons><person id="541">Boriss Mejias</person></persons></event></room><room name="Other"><event id="2813"><start>16:30</start><duration>00:30</duration><room>Other</room><title>Tea</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2813/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2717"><start>17:00</start><duration>00:50</duration><room>Washington</room><title>Patroni in 2019: What's New and Future Plans</title><abstract>Being introduced in 2015, Patoni already become one of the most popular and advanced solutions for PostgreSQL high-availability. It works together with Etcd, Zookeeper, Consul or Kubernetes API to store and retrieve PostgreSQL cluster information in a consistent way ensuring that there is only one leader at a time. Unlike the majority of existing solutions for automatic failover, Patroni requires a minimal effort to configure the HA cluster and supports autodiscovery of new nodes.

In this talk we will do a short introduction to the ideas behind Patroni, deep dive into the new features that we have released in the last year and share some plans for future development. Also we are going to cover some interesting bugs and failure scenarios which were fixed.

Patroni is a Python open-source project developed by Zalando in cooperation with other contributors on GitHub: https://github.com/zalando/patroni and being used by a lot of small and big companies around the globe.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2717/</url><track>DBA</track><persons><person id="359">Alexander Kukushkin</person><person id="319">Dmitry Dolgov</person></persons></event></room><room name="Manzoni"><event id="2632"><start>17:00</start><duration>00:50</duration><room>Manzoni</room><title>Deep Postgres Extensions in Rust</title><abstract>Postgres relies heavily on an extension ecosystem, but that is almost 100% dependent on C; which cuts out developers, libraries, and ideas from the world of Postgres. postgres-extension.rs changes that by supporting development of extensions in Rust. Rust is a memory-safe language that integrates nicely in any environment, has powerful libraries, a vibrant ecosystem, and a prolific developer community.

Rust is a unique language because it supports high-level features but all the magic happens at compile-time, and the resulting code is not dependent on an intrusive or bulky runtime. That makes it ideal for integrating with postgres, which has a lot of its own runtime, like memory contexts and signal handlers. postgres-extension.rs offers this integration, allowing the development of extensions in rust, even if deeply-integrated into the postgres internals, and helping handle tricky issues like error handling. This is done through a collection of Rust function declarations, macros, and utility functions that allow rust code to call into postgres, and safely handle resulting errors.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2632/</url><track>Internals</track><persons><person id="130">Jeff Davis</person></persons></event></room><room name="Foscolo"><event id="2595"><start>17:00</start><duration>00:50</duration><room>Foscolo</room><title>Ansible (really) loves PostgreSQL</title><abstract>*But does PostgreSQL love it back?*

Ansible saw a bunch of new modules to help manage PostgreSQL. It makes new deployment even more easier than before, including fine grain control of user access or extension management.

Having followed this talk you'll be able to set up and use Ansible for PostgreSQL and see the benefits of it. Maybe you'll even be the next one to propose a PostgreSQL module or enhancement !</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2595/</url><track>Developer</track><persons><person id="57">Cédric Villemain</person></persons></event></room><room name="Parini"><event id="2825"><start>17:00</start><duration>00:50</duration><room>Parini</room><title>Foreign tables modelling in UI</title><abstract>Life in a multi-database environment is difficult. One of the well-known solutions is to use PostgreSQL Foreign Wrappers for cross-database connections. We would like to show how you can walk through the way from connection design to the real foreign wrappers configuration in a few minutes.

Using DBeaver interface we will explain how to:
-	design logical cross-database connections/links/relationships
-	preview composite database structure and data itself
-	generate SQL scripts for foreign wrappers installation in PostgreSQL

Foreign tables modelling is not a problem any more.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2825/</url><track>Sponsors</track><persons><person id="675">Serge Rider</person><person id="477">Tatiana Krupenya</person></persons></event></room><room name="Other"><event id="2834"><start>18:30</start><duration>03:30</duration><room>Other</room><title>PostgreSQL Europe Reception</title><abstract>Join us for an informal reception at after the end of the conference day at *MiB Milano*. Drinks and snacks will be provided, along with a great chance to network with your fellow attendees. See [the website](https://2019.pgconf.eu/social/) for more details.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2834/</url><track>PGConf.EU</track><persons /></event></room></day><day date="2019-10-17"><room name="Other"><event id="2827"><start>09:00</start><duration>00:30</duration><room>Other</room><title>Registration</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2827/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2685"><start>09:30</start><duration>00:50</duration><room>Washington</room><title>Postgres Partitioning: How Far We've Come</title><abstract>Postgres has, for more than decade, allowed users to implement table partitioning in their databases, but doing so wasn't very easy until Postgres 10 happened. Postgres 10, released in 2017, took the first baby steps to improve the user experience in that area, featuring a specialized syntax to implement table partitioning and automating various crucial tasks like tuple routing, setting up the partition constraints, etc. Postgres 11, released in 2018, fixed many of the annoying limitations of partitioning of Postgres 10, offering partitioned indexes, limited forms of unique and foreign key constraints, update row movement, faster partition pruning, etc. Postgres 11 for the first time made it possible for users to seriously consider incorporating partitioning into their production databases. People with huge amounts of data to put into partitions might find it limiting that even Postgres 11 can't handle more than a few hundred partitions, whereas they would expect it to handle thousands. Postgres 12 to be released this year improves that situation to a certain extent, so that people will now be able to use up to a few thousand partitions for common set of use cases. Along with various performance improvements, there will also be new features, closing the feature gap even further.

In this talk, I will describe the partitioning functionality offered by various generations of Postgres, up to and including the latest version 12.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2685/</url><track>Developer</track><persons><person id="654">Amit Langote</person></persons></event></room><room name="Manzoni"><event id="2548"><start>09:30</start><duration>00:50</duration><room>Manzoni</room><title>How Green Was My Valley - Spatial Analytics with PostgreSQL, PostGIS, R, and PL/R</title><abstract>Increasingly today, collected data includes a spatial component. PostgreSQL + PostGIS, combined with R via PL/R, provides an awesome tool-chain for advanced spatial analytics on such data! This presentation will introduce the audience to PL/R, discuss the pros and cons of this approach to spatial data analysis, then walk through examples of advanced spatial analysis using PostgreSQL, PostGIS, and PL/R. Specifically covered:

* Overview
** Tutorial problem set
** Components
** Environment setup
* Ingest
** Admin boundaries
** Geocoding
** MODIS Raster data
* Analytics
** Simple map output
** Raster date processing
** Regional aggregation and trending</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2548/</url><track>Developer</track><persons><person id="38">Joe Conway</person></persons></event></room><room name="Foscolo"><event id="2729"><start>09:30</start><duration>00:50</duration><room>Foscolo</room><title>pg_pranks</title><abstract>Knowing some internals of PostgreSQL can be very useful when faced with an unusual situation or challenge. However, can we cover the topic in an unconventional way? Let’s say in the form of pranks for your colleagues. We will cover:
•	Disabling or changing some crucial parameters
•	Filling up the disk
•	Introducing random errors
•	Delaying replication
•	Disabling indexes
•	Making PostgreSQL fail
•	… and more
Note: Don’t try this at home. Or at work. The examples are given as a way to demonstrate some PostgreSQL behaviour and are performed by a trained professional.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2729/</url><track>Internals</track><persons><person id="222">Mladen Marinović</person></persons></event></room><room name="Parini"><event id="2577"><start>09:30</start><duration>00:50</duration><room>Parini</room><title>Moving from Oracle to PostgreSQL</title><abstract>Many people are still using Oracle and are therefore suffering. High costs, high maintenance, inflexibility and so on are just some of the things people complain about.
PostgreSQL offers a good way out and can be used as a replacement for Oracle in a nice way. The question is simply: How to move to PostgreSQL? This talk shows, how to do that and where to be careful.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2577/</url><track>Sponsors</track><persons><person id="39">Hans-Jürgen Schönig</person></persons></event></room><room name="Washington"><event id="2581"><start>10:30</start><duration>00:50</duration><room>Washington</room><title>Community roadmap to sharding</title><abstract>Sharding is one of most wanted PostgreSQL features.  Vertical scalability is limited by hardware.  Replication doesn't provide scalability in read-write performance and database size. Only sharding promises this.

However, such a brilliant feature is hard to implement.  And here is the point where different community parties should work together.  The PostgreSQL community has done a great work on foreign data wrappers and continues improving them.  Postgres Pro has experience in distributed transactions, snapshots and query planning/execution.

In this talk we will cover existing advances in sharding and present a roadmap of transforming them into a comprehensive sharding solution suitable for the main use cases.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2581/</url><track>General</track><persons><person id="64">Alexander Korotkov</person><person id="44">Bruce Momjian</person></persons></event></room><room name="Manzoni"><event id="2700"><start>10:30</start><duration>00:50</duration><room>Manzoni</room><title>Wonderful SQL features your ORMs can use (or not)</title><abstract>SQL can seem like an obscure and complex but powerful language. Learning it can be intimidating. As a developer, we can easily be tempted using basic SQL provided by the ORM. But did you know that you can use window functions in some ORMs? Same goes for a lot of other fun SQL functionalities.

In this talk we will explore some advanced SQL features that you might find useful. We will discover the wonderful world of joins (lateral, cross…), subqueries, grouping sets, window functions, common table expressions. 

But most importantly this talk is not only a talk to show you how great SQL is. This talk is here to show you how to use it in real life. What are the features supported by your ORM? And how can you use them if they don’t support them? 

Wether you know SQL or not, whether you are a developer or a DBA working with developers, you might learn a lot about SQL, ORMs, and application development using Postgres.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2700/</url><track>Developer</track><persons><person id="442">Louise Grandjonc</person></persons></event></room><room name="Foscolo"><event id="2698"><start>10:30</start><duration>00:50</duration><room>Foscolo</room><title>Business Intelligence with Window Functions in PostgreSQL 11</title><abstract>Window functions are a very useful tool. They are used for various use cases where a simple aggregation is not flexible enough: incremental totals, moving averages, etc.

PostgreSQL 11 supports the full SQL:2011 standard, with capabilities such as rows / range frames, GROUPS mode, exclusions.

In this talk we will review what users can do with window functions nowadays, and illustrate each specific feature with an example which is examined in detail.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2698/</url><track>Developer</track><persons><person id="34">Gianni Ciolli</person></persons></event></room><room name="Parini"><event id="2829"><start>10:30</start><duration>00:50</duration><room>Parini</room><title>An Expert Guide to Migrating Legacy Databases to Postgres in the Cloud</title><abstract>Licensing complexity, rising costs, and audit risk are motivating legacy database users to accelerate their migration efforts to alternatives like open source-based Postgres in compelling numbers. The presentation will discuss why legacy migrations are picking up steam and provide data showing what types of constructs are migrated most often.

Migration can present challenges, however. Some organizations are hesitant to move, citing technical, integration, and knowledge risks among the reasons. In this presentation, we will highlight the typical problems encountered and share technical solutions to overcome these issues. Additionally, we will examine alternative migration scenarios including lift-and-shift and the transformation of monolithic databases into mini/micro-services based solutions.

The presentation will conclude with a live migration demo featuring a number of the tools and technologies available to help you move your legacy database to the cloud with ease including EDB’s Migration Portal, EDB Postgres Advanced Server PL/SQL capabilities and EDB’s Cloud Database Service.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2829/</url><track>Sponsors</track><persons><person id="178">Marc Linster</person></persons></event></room><room name="Other"><event id="2814"><start>11:20</start><duration>00:30</duration><room>Other</room><title>Coffee</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2814/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2696"><start>11:50</start><duration>00:50</duration><room>Washington</room><title>When It All Goes Wrong</title><abstract>You're woken up in the middle of the night to your phone. Your app is down and you're on call to fix it. Eventually you track it down to "something with the db," but what exactly is wrong? And of course, you're sure that nothing changed recently…

Knowing what to fix, and even where to start looking, is a skill that takes a long time to develop. Especially since Postgres normally works very well for months at a time, not letting you get practice! 

In this talk, I'll share not only the more common failure cases and how to fix them, but also a general approach to efficiently figuring out what's wrong in the first place.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2696/</url><track>Developer</track><persons><person id="87">Will Leinweber</person></persons></event></room><room name="Manzoni"><event id="2742"><start>11:50</start><duration>00:50</duration><room>Manzoni</room><title>Instantaneous transaction rollback, and other advantages of versioned storage</title><abstract>PostgreSQL's approach to MVCC is based on versioned storage, and owes much to the time travel feature that appeared in the original Berkeley codebase.  An asynchronous cleanup process (VACUUM) garbage collects obsolete row versions, with additional cleanup performed by user transactions opportunistically.  This approach has significant differences to the approaches taken by other database systems, which generally either support two-phase locking, a limited form of MVCC with remnants of two-phase locking, or both.

The use of versioned storage is not purely an accident of history; it's a design trade-off with non-obvious practical advantages and disadvantages for DBAs and application developers.  This talk will focus on the advantages.

Topics covered include:

* "Instantaneous transaction rollback".  This is the term used by SQL Server to describe a key advantage of the "Accelerated Database Recovery" feature that will appear in SQL Server 2019. PostgreSQL always takes this approach to transaction rollback.

* Advantages of versioned storage for recovery and high availability, especially in cloud environments.

* How versioned storage decouples concurrency control from recovery, greatly simplifying the implementation of index access methods.

* Disadvantages of even limited use of 2PL style locks within index access methods, which PostgreSQL always avoids. There are significant locking issues with access methods that implement an inverted index or bitmap index. Coarse-grained concurrency control has to be added to support eager rollback.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2742/</url><track>Internals</track><persons><person id="165">Peter Geoghegan</person></persons></event></room><room name="Foscolo"><event id="2635"><start>11:50</start><duration>00:50</duration><room>Foscolo</room><title>The TopN extension: Maintaining top 10 lists at scale</title><abstract>Whether it's the biggest, oldest, fastest, slowest one of everyone's favorite questions about data is: What is the top 10? SQL offers easy solutions like "SELECT item, count(*) FROM data GROUP BY item ORDER BY 2 DESC LIMIT 10", but if you have a lot of data and a dashboard that can generate many ever-changing top 10 lists, then such queries don't scale at all. What we need is to be able to incrementally update top N lists as new data comes in. PostgreSQL did not have an easy way to do that yet, so we added it via the postgresql-topn extension.

In this talk, I will focus on the PostgreSQL extension postgresql-topn (new as of March 2018). TopN can provide approximate answers to these kinds of aggregation queries within reasonable and configurable error bounds. TopN is not only fast and memory-efficient but also has very interesting properties which especially shine in a distributed environment. In this talk, I will talk about the internals of TopN and how it estimates top items. At the end of this session, you will have fallen in love with the capabilities of TopN and you will be adding it to your analytics tool belt.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2635/</url><track>Developer</track><persons><person id="637">Furkan Sahin</person></persons></event></room><room name="Parini"><event id="2620"><start>11:50</start><duration>00:50</duration><room>Parini</room><title>How PostgreSQL tuning can profit from 20 years Oracle tuning</title><abstract>Tuning a database system mostly comes down to the same areas, no matter which database system it is about: Optimizer features/bugs, badly written SQL, understanding database parameters and as a final resort: Storage and operating system (mis-)configuration. PostgreSQL is no exception to that but when you try to tune PostgreSQL with a pure 20 years Oracle background there are some similarities but also major differences. One area which commonly is misunderstood is what optimizations the PostgreSQL optimizer is able to do and what it is (currently) not able to do. This is a hard lessons learned session of my long time Oracle DBA experience, with also some demos .</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2620/</url><track>Sponsors</track><persons><person id="468">Hervé Schweitzer</person></persons></event></room><room name="Washington"><event id="2738"><start>12:50</start><duration>00:50</duration><room>Washington</room><title>ZedStore - Column store for PostgreSQL</title><abstract>I and colleagues have been working on a new column store implementation for PostgreSQL, using the new table AM APIs that were introduced in PostgreSQL v12. In this presentation, I will talk about the design goals and non-goals of ZedStore, and current status of the project.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2738/</url><track>Developer</track><persons><person id="11">Heikki Linnakangas</person></persons></event></room><room name="Manzoni"><event id="2783"><start>12:50</start><duration>00:50</duration><room>Manzoni</room><title>Vacuum Through Pictures.</title><abstract>Proper Vacuum operations is an important function of any Postgres deployment. Vacuum is at the core of many Postgres operational items. Having a Postgres deployment properly tuned for vacuum is critical for all successful Postgres production instances.

Unfortunately, may people struggle with the concepts behind vacuum and auto-vacuum. Hence, DBAs and Developers become extremely confused about how to tune the critical functionality associated with them (i.e. reclaiming dead tuples, freezing tuples and analyzing tables).

This talk will cover some key concepts of Postgres Vacuum and Autovacuum and some of the concepts around properly tuning Vacuum. While talks similar to this talk has been given many times before, this talk will be differentiated by the extensive use of diagrams, illustrations and animations to present the concepts around Postgres Vacuum and tuning Postgres Vacuum. The talk will be augmented with real life stories about how tuning vacuum properly makes a difference. 

The primary audience of this talk are people who have often heard of Vacuum but have never quite understood why it is necessary and for people who do understand Postgres Vacuum but have struggled to explain it.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2783/</url><track>General</track><persons><person id="669">Tom Kincaid</person></persons></event></room><room name="Foscolo"><event id="2669"><start>12:50</start><duration>00:50</duration><room>Foscolo</room><title>How does HashJoin work in PostgreSQL and its derivates</title><abstract>HashJoin is one of the most important join implementation method, especially for OLAP databases. This talk covers how HashJoin works in PostgreSQL and its derivates like Greenplum, CitusDB. Consideration like memory limitation and MPP execution will be covered also.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2669/</url><track>Internals</track><persons><person id="273">Yandong Yao</person></persons></event></room><room name="Parini"><event id="2832"><start>12:50</start><duration>00:50</duration><room>Parini</room><title>BDR - AlwaysOn Multi-Master Clusters for Distributed PostgreSQL</title><abstract>- Introduction to Postgres-BDR
- Postgres-BDR Architecture
- High Availability, Disaster Recovery, Rolling Upgrades, Latency and Geographical Distribution with Postgres-BDR
- Common use cases for Postgres-BDR
- Making applications compliant with Postgres-BDR</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2832/</url><track>Sponsors</track><persons><person id="17">Simon Riggs</person></persons></event></room><room name="Other"><event id="2815"><start>13:40</start><duration>01:00</duration><room>Other</room><title>Lunch</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2815/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2644"><start>14:40</start><duration>00:50</duration><room>Washington</room><title>More Than a Query Language: SQL in the 21st Century</title><abstract>Did you know the purely relational dogma of SQL was already abandoned in 1999?

The last SQL standard that was limited to the relational idea was SQL-92. From SQL:1999 onwards, the SQL language was extended with non-relational operations and non-relational data structures. As much as this move was discussed at that time, it took decades until database vendors caught up with this idiomatic change. Many SQL users haven’t heard of it until today.

This talk provides the big picture on the evolution of the SQL standard and introduces some selected modern SQL features by example. You will see that SQL has changed as much as our requirements have changed over the past decades.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2644/</url><track>Developer</track><persons><person id="142">Markus Winand</person></persons></event></room><room name="Manzoni"><event id="2749"><start>14:40</start><duration>00:50</duration><room>Manzoni</room><title>Exploratory analytics and Health Big Data on PostgreSQL</title><abstract>Goals of health analytics consist in using trends to highlight the (underestimated) rising issue of antibiotic resistance, one of the biggest threats for patients safety in Europe. To do that, we need a huge amount of data that will be needed storage, management and querying in a relational schema. Of course, PostgreSQL was our choice to do that.

We will explore the ER model and simple queries which optimisation problem we ran into, and how we solved them. Then we'll explore analytics in depth using conditional expressions, aggregated values and date parsing, collecting and visualising results.

This talk aims to offer a different perspective on Postgres use cases, offering an insight of its power while doing exploratory analytics: databases are in fact the first instrument to perform data cleansing, descriptive statistics and time series analysis.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2749/</url><track>General</track><persons><person id="659">Ilaria Battiston</person></persons></event></room><room name="Foscolo"><event id="2651"><start>14:40</start><duration>00:50</duration><room>Foscolo</room><title>Deploy your own replication system with Wal2Json</title><abstract>Postgres is really great, but sometimes you have to use other technologies.
When you use several technologies, you want to keep them in sync. How can we do that ? By creating our own logical replication system between Postgres and the other technology!
This appened to allocine.com, the top first cinema related website in France. We needed to keep our Elastic Search indexes in sync with our Postgres data. Learn how we used wal2json to be able to achieve that goal without creating a labyrinthine system based on triggers. You'll see how efficient and simple this is and you'll soon be able to do the very same!</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2651/</url><track>DBA</track><persons><person id="640">mai peng</person></persons></event></room><room name="Parini"><event id="2799"><start>14:40</start><duration>00:50</duration><room>Parini</room><title>DataGrip: a smart IDE for PostgreSQL</title><abstract>For over 15 years JetBrains have strived to make effective developer tools. IntelliJ IDEA for java is the most popular of them. IntelliJ supports databases as well, and finally we in JetBrains decided to bring this functionality and our experience in programming languages to the world of SQL. That’s how DataGrip appeared.  
In this talk Maksim will tell how DataGrip helps developers by automating routine checks and corrections and speeds up developer’s production. I will also show how to extend IDE’s functionality and try to understand which actual problems we can solve in future.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2799/</url><track>Sponsors</track><persons><person id="677">Maksim Sobolevskiy</person></persons></event></room><room name="Washington"><event id="2543"><start>15:40</start><duration>00:50</duration><room>Washington</room><title>An Oracle DBA approach to troubleshoot PostgreSQL application performance</title><abstract>Coming to PostgreSQL after years of Oracle performance tuning, I realize that I approach PostgreSQL with tools and methods that are different from what a 'native' postgres DBA will start with. What made my job easier on Oracle is also available, and free, for PostgreSQL: 

 - PGIO can be more appropriate than pgbench when analyzing the raw platform performance
 - pgSentinel, with its ASH sampling approach, is more focused at the root cause than statistics and ratios
 - pg_hint_plan has its use when trying to understand the query planner decisions

All those tools with why/how/when explanations and live demo.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2543/</url><track>DBA</track><persons><person id="618">Franck Pachot</person></persons></event></room><room name="Manzoni"><event id="2781"><start>15:40</start><duration>00:50</duration><room>Manzoni</room><title>IoT with PostgreSQL</title><abstract>Internet of Things is a currently a burgeoning market, and is often associated with specialized data-stores.  However PostgreSQL is just as capable at this use-case and can offer some compelling advantages.

We’ll explore ways to store IoT data in PostgreSQL covering various ways to store and structure this kind of data.  How range types and differing types of indexes can be of use.  Also taking a quick look at some extensions designed for this use case.

Then looking at powerful SQL features which can really help when analyzing IoT data streams, and how the power of a real SQL database can be a key advantage.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2781/</url><track>Developer</track><persons><person id="424">Chris Ellis</person></persons></event></room><room name="Foscolo"><event id="2780"><start>15:40</start><duration>00:50</duration><room>Foscolo</room><title>Anonymization : GDPR and beyond</title><abstract>Since the introduction of the General Data Protection Regulation, data masking and anonymization are now mandatory in many use case where data has to flow in various ways. 

The good news is that you can use PostgreSQL to define and enforce an anonymization policy directly inside your database.  Using an open source extension called "PostgreSQL Anonymizer",  you can use various masking strategies such as randomization, faking, bluring, generalization, shuffling, partial masking, etc. 

PostgreSQL Anonymizer is a simple and effective way to protect the privacy of your users and even go beyond the GDPR requirements.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2780/</url><track>General</track><persons><person id="114">Damien Clochard</person></persons></event></room><room name="Parini"><event id="2800"><start>15:40</start><duration>00:50</duration><room>Parini</room><title>An Elephants Habitat</title><abstract>With the broad adoption of PostgreSQL in enterprise and cloud environments the elephant needs more and more specialized and sophisticated tools to meet all the challenges in those new shiny habitats. Those challenges require the integration and operating of
tools for backups, monitoring, operating, high availability, upgrades and many many more. Even small setups requires administrators to think
about all the possible open source tools available to implement their requirements.

This talk gives an overview about all the challenges involved here and tries to give an idea about possible solutions. One example is the elephant-shed project, which shows a possible way on how to build an integrated operating layer which combines many specialized open source
tools under a single roof.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2800/</url><track>Sponsors</track><persons><person id="459">Alexander Sosna</person></persons></event></room><room name="Other"><event id="2816"><start>16:30</start><duration>00:30</duration><room>Other</room><title>Tea</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2816/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2823"><start>17:00</start><duration>00:50</duration><room>Washington</room><title>Lightning Talks</title><abstract>Lightning Talks are speeches limited to 5 minutes, covering any topic. On the European PostgreSQL conference, talking about PostgreSQL or databases is encouraged. Talking about ice cream is sometimes tolerated. 
Lightning Talks are submitted on site.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2823/</url><track>PGConf.EU</track><persons><person id="2">Dave Page</person><person id="78">Harald Armin Massa</person></persons></event></room></day><day date="2019-10-18"><room name="Other"><event id="2828"><start>09:00</start><duration>00:30</duration><room>Other</room><title>Registration</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2828/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2741"><start>09:30</start><duration>00:50</duration><room>Washington</room><title>What's in a Plan?</title><abstract>PostgreSQL's EXPLAIN command is a powerful tool, allowing users to expect and understand query plans in detail. However, the output produced by EXPLAIN is not a direct representation of the plan; it omits some information and displays other information in modified form. In this talk, I'll discuss the differences between the plan as displayed by EXPLAIN and what is actually stored in the server's internal data structures. I'll also discuss why the plan includes the information it does, how that information is computed, and how that information is used at execution time. I hope that this will be helpful in understanding the behavior of the PostgreSQL planner and executor as well as in learning to write patches that modify those systems.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2741/</url><track>Internals</track><persons><person id="264">Robert Haas</person></persons></event></room><room name="Manzoni"><event id="2751"><start>09:30</start><duration>00:50</duration><room>Manzoni</room><title>Postgres Women: what is it, why does it matter and what can everyone do about it?</title><abstract>Postgres Women is a non-profit organisation to support women and other minorities to participate in the PostgreSQL environment, with the aim of promoting a safe space which encourages diversity.

This talk will focus on underlining the different aspects of the importance of an acceptant and inclusive community, and how anyone can contribute to it.

An analytical breakdown of the community will be performed, performing a survey to understand how groups are actually different in members (gender, nationality, language, …).

Statistics will be compared with the IT community as a whole, to see whether PostgreSQL is reflective of the broader IT groups, and some ideas to further encourage and respect diversity will be shared.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2751/</url><track>General</track><persons><person id="659">Ilaria Battiston</person><person id="387">Lætitia AVROT</person><person id="588">Renee Huinker</person></persons></event></room><room name="Foscolo"><event id="2688"><start>09:30</start><duration>00:50</duration><room>Foscolo</room><title>PgBouncer and a Bit of Queueing Theory</title><abstract>You have a few thousand clients connecting to your database all at once, that might not go well.  PgBouncer can help.

PgBouncer can restrict access to a database server to a configurable pool size and make excess clients wait in a queue for their turn.  Can what works in the supermarket also work for your database, or will it just result in frustrated clients?  What pool sizes, queue sizes, and timeouts will work?  At what point do you have to consider other ways to scale?  We'll work through some examples to analyze this.  Then we'll consider some mathematics and queueing theory to think about this issue more generally.  PgBouncer is but an example here; these concepts are applicable across the entire stack of scalable database applications.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2688/</url><track>DBA</track><persons><person id="503">Peter Eisentraut</person></persons></event></room><room name="Other"><event id="2817"><start>10:20</start><duration>00:30</duration><room>Other</room><title>Coffee</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2817/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2754"><start>10:50</start><duration>00:50</duration><room>Washington</room><title>You forgot to put the WHERE in the DELETE?</title><abstract>Yet another Disaster Recovery talk. User accidently deletes data, junior (and not so junior) DBA drops a table, or there’s simply a bug in the code that was deployed yesterday which is chewing your data down the drain. If you did your homework, you don’t have to worry (well, you need to worry, but not as much).
I’ll talk about DR options postgres has and how PITR can help in some scenarios.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2754/</url><track>DBA</track><persons><person id="200">Martín Marqués</person></persons></event></room><room name="Manzoni"><event id="2731"><start>10:50</start><duration>00:50</duration><room>Manzoni</room><title>May the Force of hierarchical data be with you</title><abstract>How to work with hierarhical data in relational databases? PostgreSQL suggests to use standard SQL way: WITH RECURSIVE common table expression, it's very flexible way to operate with such data. And it is so flexible and powerful that it makes it difficult for the optimizer, so it could demonstrate unimpressive performance. There is a more straightforward way to work with hierarhical data, the way is a ltree extension. Ltree has a long success story and I would like to show new improvements of it, such as new syntax and new index support</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2731/</url><track>Developer</track><persons><person id="309">Fedor Sigaev</person></persons></event></room><room name="Foscolo"><event id="2758"><start>10:50</start><duration>00:50</duration><room>Foscolo</room><title>Using PostgreSQL as a Web Server and Content Management System</title><abstract>We have recently created a new web service using just a simple WSGI/Flask Python script and PostgreSQL as the only backend. We currently use an Apache wrapper around WSGI to handle virtual hosting, security controls and authentication - but it doesn't do anything else. No other web framework or CMS is involved. An HTTP GET or POST results in a single PostgreSQL function call which queries or updates data based on the URL and internally generates and returns the necessary web page HTML. The web page rendering is done using a locally developed template based PostgreSQL extension module. Authorisation control is managed entirely within PostgreSQL by using roles and local data on who can access what (also held in PostgreSQL). Local content is provided from other PostgreSQL databases using foreign data wrappers. We end up with a robust and simple to manage service with all local functionality entirely within PostgreSQL. Scalability and redundancy could also be achieved using standard PostgreSQL features such as partitioning and replication, although this isn't something we have looked at yet. The talk would demo what we have done and run over the architecture and some of the tools used.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2758/</url><track>General</track><persons><person id="287">Tim Colles</person></persons></event></room><room name="Washington"><event id="2540"><start>11:50</start><duration>00:50</duration><room>Washington</room><title>The unbreakable, scalable Elephant: Patroni automation with Ansible</title><abstract>Patroni is one of the tools to build almost unbreakable and scalable PostgreSQL setups. Combining this with Ansible for automation and configuration management prevents human errors and simplifies the deployment. We will start with one node, scale to two and finally end up with a three node Patroni cluster in minutes, desasters included. The bad guy that does configuration changes in the background will be surprised on how fast that is corrected automatically.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2540/</url><track>DBA</track><persons><person id="616">Julia Gugel</person></persons></event></room><room name="Manzoni"><event id="2762"><start>11:50</start><duration>00:50</duration><room>Manzoni</room><title>FDWs and their utilization in real world scenarios</title><abstract>Have you ever had the need to write SQL queries to analyze data that would need to simultaneously query data from a flat file, MySQL,MongoDB, Oracle, Hadoop, a Python script and one or more different PostgreSQL nodes? It isn’t hard to imagine as modern day businesses tend to use specialized products and data stores for their special needs.

PostgreSQL’s FDW feature implements ISO Standard SQL-MED (SQL Management of External Data) which means that it enables PostgreSQL to manage and query data stored outside PostgreSQL. What it also means that PostgreSQL can talk to a host of other data sources including relational, noSQL and file based data sources.

This talk will cover the journey of PostgreSQL FDW feature in detail and focus how you can extend PostgreSQL to become the center of your data world in today’s dynamic data needs.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2762/</url><track>General</track><persons><person id="541">Boriss Mejias</person></persons></event></room><room name="Foscolo"><event id="2720"><start>11:50</start><duration>00:50</duration><room>Foscolo</room><title>Make A New Command</title><abstract>Have you ever wondered how commands in PostgreSQL are implemented? Wonder no more. You'll learn how to make a basic command from documentation to grammar to planner to executor with bits of community interaction in between. There will be C, and it will not be difficult C. Learn how!</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2720/</url><track>Developer</track><persons><person id="8">David Fetter</person></persons></event></room><room name="Other"><event id="2818"><start>12:40</start><duration>01:00</duration><room>Other</room><title>Lunch</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2818/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2735"><start>13:40</start><duration>00:50</duration><room>Washington</room><title>What's wrong with Postgres</title><abstract>Postgres is a powerful database, it continues to improve in terms of performance, extensibility, and more broadly in features. However it is not perfect. 

Here I'll cover a highly opinionated view of all the areas Postgres falls flat, with some rough thought ideas on how we can make it better. Opinions are all informed by 10 years of interacting with customers running literally millions of databases for users.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2735/</url><track>General</track><persons><person id="144">Craig Kerstiens</person></persons></event></room><room name="Manzoni"><event id="2795"><start>13:40</start><duration>00:50</duration><room>Manzoni</room><title>Building iFood's content search platform with PostgreSQL</title><abstract>iFood is the leading online food delivery service in Latin America, with operations in Brazil, Mexico and Colombia, currently having more than 17 millions of orders monthly in the platform and growing around than 130% a year!

The tech stack consists of hundreds of micro-service, with hundreds of databases (most running on top of PostgreSQL). With such architecture, we had the challenge to build an API for our mobile apps and website capable of indexing the contents of those services/databases in a single place, with high scalability, a lot of filters and search capabilities and geo-located. And it should handle more than 10K TPS.

All services owning the information were already on PostgreSQL, enabling us to use PG 10 built-in logical replication to synchronize many instances into a single one, and build a different schema specifically designed for search. This instance is then replicated on many AWS EC2 instances using Auto Scalling Group and the application connects on them through a Network Load Balancing, enabling us to achieve fast writes on the indexation (after changed data is available after a few milliseconds to end users) and elasticity (running more servers on peak hours). Enabling us to achieve and overcome our 10K TPS.

Besides from logical replication, this system uses a lot of loved features from PostgreSQL, like: full text search + pg_trgm to build search box (and the ugly parts of it), PostGIS for geo-location, range types for shift hours, and many others.

On this presentation I'm going to show this architecture, the good and bad things we've found while building it and after running in production.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2795/</url><track>Developer</track><persons><person id="671">Matheus de Oliveira</person></persons></event></room><room name="Foscolo"><event id="2755"><start>13:40</start><duration>00:50</duration><room>Foscolo</room><title>Converting 85% of Dutch primary schools from Oracle to PostgreSQL</title><abstract>This case study describes migrating the most used application for primary schools in the Netherlands from Oracle to PostgreSQL. The application uses a multi-tenant, single schema database (i.e. 6000 schools in a single database) and runs using a typical Java EE frontend.

You will learn about our application architecture, hardware platform, reasons for switching, migration strategies considered and the results of our migration. 

Since the CFP closes one week before our actual migration we can't reveal the results in this abstract, but the presentation will capture all the things that went wrong and well.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2755/</url><track>General</track><persons><person id="665">Martijn Dashorst</person></persons></event></room><room name="Other"><event id="2819"><start>14:30</start><duration>00:30</duration><room>Other</room><title>Tea</title><abstract /><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2819/</url><track>Breaks</track><persons /></event></room><room name="Washington"><event id="2740"><start>15:00</start><duration>00:20</duration><room>Washington</room><title>What Microsoft is doing with Postgres &amp; the Citus Data acquisition</title><abstract>Many people have asked us: “Why did Microsoft acquire Citus Data?” and “What do you plan to do with the Citus open source extension to Postgres?” Come join us to see the exciting work we are doing with Postgres and open source at Microsoft.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2740/</url><track>Platinum Sponsor Keynotes</track><persons><person id="565">Utku Azman</person></persons></event><event id="2790"><start>15:25</start><duration>00:20</duration><room>Washington</room><title>Growing the PostgreSQL Community</title><abstract>How far has the open source PostgreSQL Community grown? How much farther can it grow? How will we get there?</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2790/</url><track>Platinum Sponsor Keynotes</track><persons><person id="17">Simon Riggs</person></persons></event><event id="2660"><start>15:50</start><duration>00:20</duration><room>Washington</room><title>Supporting High-Security PostgreSQL</title><abstract>PostgreSQL is more and more used for critical applications. Therefore we see more and more demand for high-security PostgreSQL, high-availability and encryption. 
PostgreSQL TDE, Patroni, and many other tools can help to achieving those goals. This talk will provide you with a quick tour through those tools.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2660/</url><track>Platinum Sponsor Keynotes</track><persons><person id="39">Hans-Jürgen Schönig</person></persons></event><event id="2713"><start>16:15</start><duration>00:20</duration><room>Washington</room><title>Why Is This the Postgres Moment?</title><abstract>Postgres has built up a tremendous head of steam: #1 on the DB Engines ranking for two consecutive years, the most popular relational database in containers, a vibrant and fast growing user community, and growing commercial support. All signs are pointing to this being Postgres’ moment. 

But, none of this is happening by accident. Decades of development from the community and the commitment and investment of commercial companies has transformed Postgres into an extraordinary technology, ready to compete and win against traditional proprietary database solutions. 

Join Ed Boyajian, 20-year open source veteran and CEO of EnterpriseDB, as he outlines how EDB, one of the leading commercial supporters of Postgres, is building on this momentum to offer global enterprises a reliable, flexible and innovative alternative to legacy databases</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2713/</url><track>Platinum Sponsor Keynotes</track><persons><person id="33">Ed Boyajian</person></persons></event><event id="2820"><start>16:40</start><duration>00:30</duration><room>Washington</room><title>So long, and thanks for all the fish</title><abstract>Closing remarks of the conference. Join us as for a light hearted review and wrap up the events of the week.</abstract><url>https://www.postgresql.eu/events/pgconfeu2019/schedule/session/2820/</url><track>PGConf.EU</track><persons><person id="2">Dave Page</person><person id="1">Magnus Hagander</person></persons></event></room></day></schedule>