PostgreSQL: The LZ4 Compression Dance

Transcript

Hey there, fellow developers! Welcome back to another episode of the PostgreSQL podcast. It's March 5th, 2026, and I'm here with my virtual coffee mug, ready to dive into some really interesting changes happening in the PostgreSQL world.

You know, sometimes the most fascinating stories in software development aren't about the features that land perfectly - they're about the journey to get there. And today's main story is exactly that kind of tale.

Let's talk about what I'm calling "the LZ4 compression dance." Michael Paquier and the team have been working on changing the default compression algorithm for TOAST data from the older pglz to LZ4. Now, if you're not familiar with TOAST - that's PostgreSQL's way of handling large data that doesn't fit nicely in regular table rows. Think big text fields, images, that sort of thing.

Here's where it gets interesting. The team initially tried to make LZ4 a hard requirement for all builds, but the PostgreSQL buildfarm - that's their continuous integration system - absolutely hated it. Over 60% of the build machines didn't have LZ4 installed! So they had to revert the change mid-stream.

But here's what I love about this story - they didn't give up. Michael came back with a more elegant approach. Instead of forcing everyone to have LZ4, the new version simply says "if you've got LZ4 available when you build PostgreSQL, we'll use it as the default. If not, we'll stick with pglz." This is such a smart compromise because LZ4 really is better - it uses less CPU and generally compresses better than the old algorithm.

This whole saga really shows how thoughtful the PostgreSQL team is about backward compatibility and real-world deployment scenarios. They could have just said "everyone needs to install LZ4," but instead they found a path that benefits users who can use it while not breaking existing setups.

Moving on to some other great improvements - Andrew Dunstan added a really useful feature to pg_restore. There's now a `--no-globals` option that lets you skip restoring global objects like roles and tablespaces when you're restoring from a pg_dumpall archive. This is super handy when you just want to restore specific databases without messing with the global configuration of your target server.

Tom Lane also fixed an interesting issue with hash join estimation. The old code was trying to be clever about predicting bucket sizes for hash joins, but sometimes it would come up with impossible values - like probabilities greater than 100%. The new approach is much cleaner and should help PostgreSQL make better decisions about which table to use as the hash table in joins.

There were also some nice quality-of-life improvements. Fujii Masao clarified in the documentation that the COLUMN keyword is optional in ALTER TABLE commands. You can write either `ALTER TABLE foo ADD COLUMN bar` or just `ALTER TABLE foo ADD bar` - both work the same way. Sometimes the best improvements are the ones that reduce confusion!

For today's focus, if you're working with PostgreSQL and handling large data, this is a great time to check if your build has LZ4 support enabled. The performance improvements for TOAST compression can be really significant, especially if you're dealing with lots of text data or JSON documents. You can check your current setting with `SHOW default_toast_compression` and see if LZ4 is available in your build.

Also, if you're doing database migrations or working with pg_dump and pg_restore, definitely check out that new `--no-globals` flag. It could save you some headaches when you need fine-grained control over what gets restored.

That's a wrap for today's episode! I love seeing how PostgreSQL continues to evolve - not just with flashy new features, but with thoughtful improvements that make developers' lives easier. The LZ4 story really shows how good software development is as much about the process and community as it is about the code.

Keep building awesome things, and I'll catch you next time!