How to get data from Oracle to PostgreSQL and vice versa

PostgreSQL has become a reality in a lot of shops today. In most cases PostgreSQL is established beside the current Oracle deployment and quite soon one question pops up regularily: How can we push data from Oracle to PostgreSQL and vice versa? Way back, in March 2001, a new extension to the SQL standard made it's way to define common APIs for managing external data: SQL/MED (ISO/IEC 9075-9:2008). The PostgreSQL community picked that up quite fast and implemented a framework for plugging in so called foreign data wrappers back in 2011 with PostgreSQL 9.1. Since then a wide range of these foreign data wrappers popped up and thanks to those, PostgreSQL today is able to integrate data from almost every external source, no matter if it is coming from flat files, other relational database systems or even unstructured sources. In this talk we will look at the foreign data wrapper for Oracle and how it can be used to get data from Oracle to PostgreSQL. But this is not a one way game: data can also be pushed from PostgreSQL to Oracle, and this might become important depending on the requirements. It is guaranteed that this talk is splitted by half: Slides and a lot of demos.

High-Performance PostgreSQL

PostgreSQL is one of the leading open-source databases. Out of the box, the default PostgreSQL configuration is not tuned for any particular workload. The default configuration is designed in such a way that PostgreSQL can run on any system using minimum resources. Consequently, a default installation of PostgreSQL does not give optimum performance on the high-performance machine because it is set up to use all available resources. PostgreSQL provides mechanisms that allow you to tune your database according to your workload and machine specification. Outside of PostgreSQL, though, we can tune the Linux kernel to allow the database load to work optimally. In this talk, we will learn how to tune some of the PostgreSQL’s parameters, and we will see the effect of that tuning, but we will focus on demonstrating how to tune Linux for better Postgres performance. As there are so many Linux kernel parameters that can be tuned to improve the performance of PostgreSQL, I will also share the results of benchmarks obtained when tuning some of the Linux parameters.

Updating Materialized Views Automatically and Incrementally

Materialized view is a feature to store the results of view definition queries in DB in order to achieve faster query response. However, the data in the view gets stale after underlying tables are modified. Therefore, view maintenance is needed to keep the contents up to date. PostgreSQL has REFRESH MATERIALIZED VIEW command for updating a materialized view, but this command needs to recompute the contents from scratch, so this is not efficient in cases where only a small part of a base table is modified.

Incremental View Maintenance (IVM) is a technique to maintain materialized views efficiently, which computes and applies only the incremental changes to the materialized views instead of recomputing. This feature is required for updating materialized views rapidly but not implemented on PostgreSQL yet.

Therefore, we developed IVM on PostgreSQL and are proposing to implement this as a core feature. The patch is now under discussion on the hackers mailing list. Our implementation allows materialized views to be updated automatically and incrementally when a underlying table is modified. You don't need to write your own trigger function for updating views. As a result of continuous development, the current implementation supports some aggregates, subqueries, self-join, outer joins, and CTEs (WITH clauses) in a view definition query. The result of performance evaluation using TPC-H queries shows that our IVM implementation can update a materialized view more than 200 times faster than re-computation by REFRESH command.

In this talk, we will describe our IVM implementation and its features.

All about PostgreSQL Security

PostgreSQL provides different levels of security. This talk will cover all the available security techniques used in PostgreSQL 13. We’ll look at client-side security (LibPq, JDBC) through to server-side security. It will cover all supported authentication methods and the pros and cons of all these methods. Some of the key features of the talk are:

• Introduction to Cryptography
• SSL, TLS, GSSAPI, and OpenSSL
• Client-Side Encryption
• Securing Authentication
• Securing Data on the disk
• Securing Backup & Basebackup
• Securing Replication
• Database Roles and Privileges

It’s important to be familiar with all the security levels such as (1)network-level security (2) on-disk security (3) row-level, (4), and column level security. The talk will cover all the aspects with some real-life use cases and examples.