Sammlung von Newsfeeds
Wellingtone Luvonga: Multi-Region PostgreSQL Disaster Recovery and Failback with Crunchy PGO
You have probably read a dozen tutorials on setting up PostgreSQL High Availability (HA). On paper, it looks simple: spin up a primary instance, spin up a standby, and let them replicate.
Floor Drees: EDB is ready for Valencia: Meet the Team at PGConf EU 2026
Umair Shahid: Choosing the Right PostgreSQL Partition Key
Partitioning gets sold as a performance switch. You flip it on a big table, and the slow queries get fast. Most of the time, that is exactly what happens. But there is a version of this where you do all the work, split a huge table into clean partitions, and the slow queries stay exactly as slow as they were. The table is partitioned. Nothing got better.
Christophe Pettus: All Your GUCs in a Row: integer_datetimes
Regina Obe: PostGIS 3.7.0beta2
The PostGIS Team is pleased to release PostGIS 3.7.0beta2! Best Served with PostgreSQL 19 Beta2 and GEOS 3.15.0beta2.
This version requires PostgreSQL 14 - 19beta2, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed.
Vibhor Kumar: The Enterprise AI Trust Stack: How OWNS, CALM, and ORBIT Fit Together
Enterprise AI doesn’t fail because strategy was wrong. Or because the platform wasn’t ready. Or because the execution layer broke.
It fails because organizations treat those as three different conversations — run by three different teams, on three different timelines — instead of what they actually are: three altitudes of the same question.
Zhang Chen: Why I Dare to Call Myself a “PostgreSQL Database Recovery Expert”
Christophe Pettus: All Your GUCs in a Row: ignore_system_indexes
Devrim GÜNDÜZ: Release Radar: A Self-Hosted Watchtower for Upstream Releases (and Why It Matters for PGDG Packaging)
Release Radar, a self-hosted project written by Claude and me, is built to close exactly that gap.
** What it does
Shaun Thomas: Looking Forward to Postgres 19: Syntax Potpourri
Before diving into this final post covering new Postgres 19 features, I just want to say it's been a wild ride. Postgres 19 has been a veritable treasure trove of enhancements, perhaps more than any previous release; or maybe that's just my perception. Usually I just skim through the release notes and nod along, sometimes jotting down things that look interesting for later study. Maybe calling out each element that caught my eye was the right thing to do, to really show how far Postgres has come since the last release, rather than simply accepting the status quo.
Cornelia Biacsics: Contributions for week 29 & 30
The Talk Selection Committee of PGConf.EU 2026 met to finalize the conference schedule:
Christophe Pettus: All Your GUCs in a Row: ignore_invalid_pages
Andrei Mironov: PostgreSQL Row-Level Security for AI Agents: A Testable Setup
Pavel Stehule: initial integration lua language to psql
Antony Pegg: Postgres for Agentic AI: Your Database Is a Compute Layer, Not a Parking Lot
PostgreSQL is already the default database for agentic AI. That question is settled. But the more agentic your workloads get, the more your database needs to do. Models and workflows flood it with signals, state, memory, and checkpoints, and most teams just absorb the flood, treating PostgreSQL like a parking lot rather than a compute layer. The people building these systems are AI engineers, not database people.
Gabriele Bartolini: CNPG Recipe 26 - Extension image catalogs
CloudNativePG lets the ClusterImageCatalog carry extension images alongside the operand, a capability every currently supported release already has, so a Cluster manifest only needs to name an extension and nothing else. This recipe deploys the community’s extension catalog and shows the operator resolving pgvector’s image, paths and dependencies from a single, versioned source of truth per PostgreSQL major version.
Mayur B.: EXPLAIN ANALYZE the PGConf.EU CFP
What I learned after moving from conference volunteer duty to the other side of the Call for Papers.
Christophe Pettus: All Your GUCs in a Row: ignore_checksum_failure
Radim Marek: The DISTINCT in your COUNT
Here is a query that shows up in every analytics workload:
SELECT count(DISTINCT user_id) FROM events;It looks like the cheapest possible thing: count the distinct users. On a machine with cores to spare you would expect Postgres to throw a few parallel workers at it, the way it does for almost any large scan. It does not. That one keyword, DISTINCT, switches off parallel query for the entire statement, and the larger your table the more it costs you. No setting or index changes that; the reason is in how the aggregate has to execute.
Seiten
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- …
- nächste Seite ›
- letzte Seite »

