Neues vom PostgreSQL Planet

In this post, I walk through integrating JFrog Artifactory with Fujitsu Enterprise Postgres and using Transparent Data Encryption to encrypt the Artifactory metadata stored in the database.

Last week we had our September PostgresEDI meetup, the first since postgres.scot went up as the home for Postgres events in Scotland.

Two BM25 optimizations and benchmark configuration changes inspired by PlanetScale's TIN benchmarks make ParadeDB's text search faster without changing its document identifiers.

Over the past month, several major features got reverted from Postgres 19. At this point, even if everything else goes perfectly, Postgres 19 will be released about a month later than originally planned. A couple recent blog posts seem to suggest the reverts happened due to AI finding complex bugs in those patches, with fixes way too invasive this late in the development cycle. I don’t think that narrative matches reality, and I think it matters to correct that.

Unique constraints in multi-tenant PostgreSQL 17, tested: per tenant or global, soft delete, case, NULLs, ON CONFLICT, and what a duplicate-key error reveals.

Deleting one tenant from a shared PostgreSQL 17 database, measured: cascade, batches or dropping a partition; locks, batch size, disk space, what stays behind.

count(*) per tenant in PostgreSQL 17, measured: why it got 5× slower for the largest tenant, when estimates are wrong, and what a counter row costs under load.

A trigger-based audit log in PostgreSQL 17, measured: row against statement triggers, full rows against changed columns, and row-level security on the log.

One tenant queues 1,000 jobs, ten others five each: FIFO against round-robin with SKIP LOCKED in PostgreSQL 17, measured, plus a 10-second planner trap.

What an RLS policy costs in PostgreSQL 17: function volatility, the (select …) wrapper, membership subqueries and the leakproof rule that disables your index.

RLS behind PgBouncer in transaction mode, measured: which tenant context leaks, what SET LOCAL does outside a transaction, and one plan shared by tenants.

Query hints: You asked for it, Postgres 19 gave it to you. Now, they are just waiting to see how you use it.

For years the Postgres community was against adding support for hints. They felt if you had correctly analyzed tables, the Postgres query planner would make the right choice. And they're not wrong, for the most part. Yet many DBAs and developers will tell you of a time when a plan suddenly changed or something was saved by a hint. We can debate the good and bad elements of hints, but the cool thing is that you will soon have a choice in Postgres 19+.

Out now on GitHub and PGXN, pg_clickhouse v0.11.0 and the chdb extension v0.1.2 continue our dogged focus on cross-database compatibility. A slew of these enhancements derive from our header-only C libraries, clickhouse-c and pg-clickhouse-c. Let's take a look at just three of the changes in these releases.

What a character {#what_a_character}

`max_wal_size` is a checkpoint trigger, not a maximum—and the real cost is paid by setting it too low, not too high.

This is my personal experiment, not an official Apache Cloudberry release.

Since 2017 I have been keeping an eye on the PostgreSQL ecosystem for analytics and data warehousing. At work I had used AWS Redshift, with all the drawbacks and inconveniences a developer gets from a fork of an old PostgreSQL. To my mind, the ideal PostgreSQL-based solution should run on the latest PostgreSQL release, be built as an extension, be easy to start locally in a container for tests, and work with the latest versions of existing extensions such as PostGIS and pgvector.

After trying not to add any Rust packages to the PostgreSQL RPM repository, I finally bit the bullet and pushed pgrx and postgresql_anonymizer to the RPM repos, along with packaging guidelines:

https://github.com/pgdg-packaging/pgdg-rpms/wiki/Packaging-Rust-extensions-(pgrx

Some limitations exist for now:

https://github.com/pgdg-packaging/pgdg-rpms/wiki/Packaging-Rust-extensions-(pgrx)#supported-distributions

Hoping to add RHEL 10.3 and 9.9 support in November.

Enjoy!

Errata: the max_connections post told you to size that parameter for “the replication connections.” On 12 and later, don’t. WAL senders have their own seats, sized by this parameter, and have not drawn from max_connections since PostgreSQL 12. The rest of that post stands; that clause is wrong fo…

PostgreSQL 18 ships uuidv7() in core. No extension, no application code. So the old question comes back: if you want UUID keys, does the version matter?

I loaded 5 million rows three ways and measured. Short answer: UUIDv7 inserted in 27 seconds, UUIDv4 in 46. The v4 index came out 29% bigger. Random lookups by key cost the same.

Setup

One table per run:

CREATE TABLE t (id , payload text NOT NULL);

The key was one of:

The SQL standard is written by a committee I sit on, so what people think it ought to contain is a professional interest of mine. The various social media algorithms seem to know this, and they serve me mostly relevant content. This one came via LinkedIn, and here it is in full:

Use PostgreSQL ALTER FUNCTION SET work_mem to stop one function's sorts spilling to disk without a global change. A production fix: 150 GB a day to 0.