Let's see, with practical examples, how to make Python and PostgreSQL talk to each other seamlessly: how to connect to a server, how to exchange data, manage transactions, passing parameters in a safe and expressive way, how to manage notifications.
We will cover psycopg2, the most used PostgreSQL adapter for Python, but also look and the up and coming psycopg3: what will remain the same, what will change, how to better organise a Python program to make the most of PostgreSQL.
MobilityDB is a moving object database extension to PostgreSQL and PostGIS. It has types and functions for storing an querying geospatial trajectories, as first class citizens. The main type is called tgeompoint (temporal geometry point). It represents a complete movement track of a geometry point, such as a car, a bird, or a person. The function speed(tgeompoint) computes the time varying speed of the object, as a tfloat (temporal float). Similar to these examples, MobilityDB has 6 temporal types, and over 300 functions. As such, it is a function-rich platform for Mobility Data Management.
In this tutorial you will:
- learn about moving object databases
- write MobilityDB SQL queries and explore a database of geospatial trajectories
- walk through the different type, indexes, and functions of MobilityDB.
Some OS distributions do not have a pcs configuration utility to create a high availability cluster PostgreSQL. In this case, the crm utility from the crmsh package will help us. It is more difficult to use, but powerful and effective.
In my master class, I will show how to use this utility, as well as configure a failover cluster in different configurations.
Is deploying Postgres in Kubernetes just repackaging it into a container? Can’t Postgres leverage the wide range of Cloud-Native software and integrate well with K8s? Join this journey that will cover and demonstrate, with demos running on StackGres:
- How to structure Postgres into an init-less container, plus several sidecar containers for connection pooling, backups, agents, etc.
- Defining high level CRDs as the single API to interact with the Postgres operator.
- Using K8s RBAC for user authentication of a web UI management interface.
- Using Prometheus for monitoring; bundling a node, Postgres and PgBouncer exporters together.
- Proxying Postgres traffic through Envoy. Terminate Postgres SSL with an Envoy plugin, that also exports wire protocol metrics to Prometheus.
- Using Fluentbit to capture Postgres logs and forward them to Fluentd, which stores them on a centralized Postgres database.
You will be able to follow the session on your own Kubernetes cluster, and go from zero to a Postgres hero on Kubernetes with little effort! Create in minutes your own Postgres-as-a-Service on your Kubernetes.
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.
There are two types of SQL query analysis:
"Macro": analyzing the workload as a whole (three major approaches: using metrics provided by pg_stat_statements or similar, log analysis with pgBadger or similar, and sampling of pg_stat_activity)
"Micro": diving into details of single query execution (EXPLAIN command being the central tool here)
And there are huge gaps between them that become noticeable at scale. The main challenges:
- Switching between "macro" and "micro" without a huge overhead
- Verifying optimization ideas reliably
- Deploying changes risk-free
Solving these tasks at a scale requires advanced DBA experience and–sometimes–intuition. Or better tools that (fortunately!) very recently started to appear.
In this tutorial, we will learn how to establish a smooth and seamless SQL optimization process in your organization: * what tools should you choose in your particular case? * how to close the gaps mentioned above?