PgConf.Russia 2016

Enterprises need enterprise-level databases. The existing Postgres clustering solutions are not supported by the community. Postgres needs a community-supported cluster solution. There have been multiple attempts like Postgres-XC/XL, but they are still being developed separately and have low chance to be accepted by the community. Other solutions, like pg_shard, plproxy, FDW-based, etc. lack the notion of global transactions. We developed a Distributed Transaction Manager (DTM) as a Postgres extension to achieve global consistency over a number of Postgres instances. To demonstrate the capabilities of the DTM we present examples of distributed transaction processing using pg_shard and postgres_fdw. We hope that the proposed approach will be included into Postgres 9.6. This will make the development of the clustering solutions easier for all interested parties.

Multicorn is a generic Foreign Data Wrapper which goal is to simplify development of FDWs by writing them in Python.

We will see:

• what is an FDW what Multicorn is trying to solve how to use it, with a brief tour of the FDWs shipping with Multicorn.
• how to write your own FDW in python, including the new 9.5 IMPORT FOREIGN SCHEMA api.
• the internals: what Multicorn is doing for you behind the scenes, and what it doesn't

After a presentation of FDWs in general, and what the Multicorn extension really is, we will take a look at some of the FDWs bundled with Multicorn.

Then, a complete tour of the Multicorn API will teach you how to write a FDW in python, including the following features:

• using the table definition
• WHERE clauses push-down
• output columns restrictions
• influencing the planner
• writing to a foreign table
• IMPORT FOREIGN SCHEMA
• ORDER BY clauses pushdown
• transaction management

This will be a hands-on explanation, with code snippets allowing you to build your own FDW in python from scratch.

B-tree is the most widely used index type in PostgreSQL. This data structure and concerned algorithms are developed about forty years ago. But there is still an area for optimisations. In this presentation I'm going to talk about B-tree data structure, and its features important for the optimal index usage. Furthermore, I'll present a couple of new features which are expected to be included in PostgreSQL 9.6 release.

Common Java wisdom is to use PreparedStatements and Batch DML in order to achieve top performance. It turns out one cannot just blindly follow the best practices. In order to get high throughput, you need to understand the specifics of the database in question, and the content of the data.

In the talk we will see how proper usage of PostgreSQL protocol enables high performance operation while fetching and storing the data. We will see how trivial application and/or JDBC driver code changes can result in dramatic performance improvements. We will examine how server-side prepared statements should be activated, and discuss pitfalls of using server-prepared statements.