Neues vom PostgreSQL Planet
Hans-Juergen Schoenig: Counting Customers in PostgreSQL
As a database consulting company, we are often faced with analytics and reporting related tasks which seem to be easy on the surface but are in reality not that trivial. The number of those seemingly simple things is longer than one might think, especially in the area of reporting
Hubert 'depesz' Lubaczewski: Do you really need tsvector column?
Josef Machytka: PostgreSQL 18 enables data‑checksums by default
As I explained in my talk on PostgreSQL Conference Europe 2025, data corruption can be silently present in any PostgreSQL database and will remain undetected until we physically read corrupted data. There can be many reasons why some data blocks in tables or other objects can be damaged. Even modern storage hardware is far from being infallible. Binary backups done with pg_basebackup tool – which is very common backup strategy in PostgreSQL environment – leave these problems hidden. Because they do not check data but copy whole data files as they are.
Radim Marek: Beyond Start and End: PostgreSQL Range Types
One of the most read articles at boringSQL is Time to Better Know The Time in PostgreSQL where we dived into the complexities of storing and handling time operations in PostgreSQL. While the article introduced the range data types, there's so much more to them. And not only for handling time ranges.
Cornelia Biacsics: Contributions for week 44, 2025
PostgreSQL received attention through the following contributions at Data Stack Conf 2025 on Oct 29, 2025:
Speaker
- Radoslav Stanoev
 - Pavlo Golub
 - Lætitia Avrot
 - Valeria Bogatyreva
 - Devrim Gündüz
 
PostgreSQL Booth Staff
- Devrim Gündüz
 - Pavlo Golub
 
Gabriele Quaresima spoke at Cloud Native Bergen on Tuesday, October 28, 2025.
Dave Stokes: Migration From MySQL To PostgreSQL In Five Steps Using DBeaver
I wrote a post in my MySQL blog on migrating from MySQL to PostgreSQL using DBeaver. You can pass it along to your acquaintances who want to get off the Dolphin and on the Elephant.
Not only will DBeaver move your tables and data, but you can compare them afterwards. In the post, I outline the process in five steps. DBeaver will let you do it in four.
Tomas Vondra: Don't give Postgres too much memory
From time to time I get to investigate issues with some sort of a batch process. It’s getting more and more common that such processes use very high memory limits (maintenance_work_mem and work_mem). I suppose some DBAs follow the logic that “more is better”, not realizing it can hurt the performance quite a bit.
Let me demonstrate this using an example I ran across while testing a fix for parallel builds of GIN indexes. The bug is not particularly interesting or complex, but it required a fairly high value for maintenance_work_mem (the initial report used 20GB).
Umair Shahid: What Are “Dirty Pages” in PostgreSQL?
PostgreSQL stores data in fixed‑size blocks (pages), normally 8 KB. When a client updates or inserts data, PostgreSQL does not immediately write those changes to disk. Instead, it loads the affected page into shared memory (shared buffers), makes the modification there, and marks the page as dirty. A “dirty page” means the version of that page in memory is newer than the on‑disk copy.
Nikolay Samokhvalov: #PostgresMarathon 2-011: Prepared statements and partitioned tables — the paradox, part 3
In #PostgresMarathon 2-009 and #PostgresMarathon 2-010, we explored why execution 6 causes a lock explosion when building a generic plan for partitioned tables — the planner must lock all 52 relations because it can't prune without parameter values.
Today we'll test what actually happens with different plan_cache_mode settings.
Paolo Melchiorre: Install PostgreSQL 18 on Ubuntu 25.10
How-to guide for installing PostgreSQL version 18 on Ubuntu, after a fresh installation of version 25.10 (Questing Quokka).
Nikolay Samokhvalov: #PostgresMarathon 2-010: Prepared statements and partitioned table lock explosion, part 2
In #PostgresMarathon 2-009, we focused on Lock Manager's behavior when dealing with prepared statements and partitioned tables.
And observed a lock explosion in our simple synthetic example: from 8 locks (custom plans) during first 5 calls, to 52 locks (building generic plan) in the 6th call, to 13 locks (using cached generic plan) in the 7th and subsequent calls. We left with questions:
Hubert 'depesz' Lubaczewski: Waiting for PostgreSQL 19 – Add psql PROMPT variable for search_path.
Cornelia Biacsics: Head of Marketing experiences @PGConf.EU 2025 – A Riga Recap
PostgreSQL Conference Europe 2025 in Riga has officially come to an end — and what remains are the impressions, emotions, moments, and the incredible vibe that remind me why we do what we do.
I met so many inspiring people, had conversations with some of my role models, and wore many hats throughout the conference.
Nikolay Samokhvalov: #PostgresMarathon 2-009: Prepared statements and partitioned table lock explosion, part 1
In #PostgresMarathon 2-008, we discovered that prepared statements can dramatically reduce LWLock:LockManager contention by switching from planner locks (which lock everything) to executor locks (which lock only what's actually used). Starting with execution 7, we saw locks drop from 6 (table + 5 indexes) to just 1 (table only).
There we tested only a simple, unpartitioned table. What happens if the table is partitioned?
Hans-Juergen Schoenig: The Future of CYBERTEC and PostgreSQL
For this second entry into our blog feature to celebrate 25 years of CYBERTEC, our CEO gave some interesting insights into what he expects of the future - for the company as well as PostgreSQL as a whole.
CYBERTEC in another 25 yearsInterviewer: Let's talk about the future. Where do you think you see CYBERTEC in another 25 years?
Jeremy Schneider: Explaining IPC:SyncRep – Postgres Sync Replication is Not Actually Sync Replication
Postgres database-level “synchronous replication” does not actually mean the replication is synchronous. It’s a bit of a lie really. The replication is actually – always – asynchronous. What it actually means is “when the client issues a COMMIT then pause until we know the transaction is replicated.” In fact the primary writer database doesn’t need to wait for the replicas to catch up UNTIL the client issues a COMMIT …and even then it’s only a single individual connection which waits. This has many interesting properties.
Robert Bernier: Troubleshooting PostgreSQL Logical Replication, Working with LSNs
Mayur B.: Slonik on the Catwalk: PGConf.EU 2025 Recap
      I volunteered as a room host and Slonik guide.
      Best gig: posing our elephant. The photographer had runway-level ideas. Slonik delivered every single time.
    
Rhys Stewart: Trigger Happy: Live edits in QGIS
Shaun Thomas: Returning Multiple Rows with Postgres Extensions
Creating an extension for Postgres is an experience worthy of immense satisfaction. You get to contribute to the extension ecosystem while providing valuable functionality to other Postgres users. It’s also an incredibly challenging exercise in many ways, so we’re glad you’ve returned to learn a bit more about building Postgres extensions.In the previous article in this series, we discussed creating an extension to block DDL.
Seiten
- 1
 - 2
 - 3
 - 4
 - 5
 - 6
 - 7
 - 8
 - 9
 - …
 - nächste Seite ›
 - letzte Seite »
 

