PostgreSQL 16 was released last week. This is the story of a feature.
We continue our exploration of PostgreSQL build system performance. A long time ago, I wrote an article about how to optimize the performance of
make install. This was quite helpful, as it reduced the time from 10.493 s by default to 1.654 s with some tweaks (6x faster). Now, with different hardware, a much newer PostgreSQL, and a new build system looming, let’s take another look.
After the recent news that HashiCorp has changed the licenses of its hitherto-open-source products, I thought it would be a good time to take a look at the licenses that have sprung up around PostgreSQL and adjacent and related communities, since quite a bit has changed there recently, and it’s hard to keep track.
We have talked before about how ccache affects build times of PostgreSQL. Now I was wondering how different build directory layouts affect ccache. I was never a user of separate build directories in the make build system (“vpath builds”), so this never concerned me much. But now with Meson this is required.
In a recent article, I compared the compilation times of PostgreSQL using different compilers. In the comments, I was asked for numbers for the new Meson build machinery. Let’s do that now.
In a recent article, I covered the parametric ICU collation customization settings. In today’s article, I will describe the other major collation customization option: the alternative collation types selected with the
cokey in the locale identifier.
The news today is that SQL:2023, the new version of the SQL standard, has been published by ISO.
What’s the fastest compiler for PostgreSQL? Let’s take a look.
ICU use is becoming more prominent in PostgreSQL. One of the benefits that ICU offers is a lot of customization options for collations. Some of these are given as examples in the PostgreSQL documentation, but I have always found it hard to get complete and easily-accessible information about this.
In 2009, I wrote a blog post How to submit a patch by email, which became popular at the time and also ended up in the PostgreSQL wiki. That article was written pre-Git and pre-cfbot, so maybe it’s time for a refresher, as we head into the next PostgreSQL development cycle.
Here is a fun little view on the progress of PostgreSQL. Consider the number of “CREATE SOMETHING” commands each release contains. As more features are added over time, more such CREATE commands are added.
In a previous article, I introduced what is new in SQL:2023. Now I want to show the status of SQL:2023 support in PostgreSQL. See the previous article for details on these features.
In a previous article, I described how collation works internally in PostgreSQL in general. In that article, we left open how collation of punctuation and whitespace works. This is where a lot of users get confused. Let’s look at that now.
SQL:2023 has been wrapped. The final text has been submitted by the working group to ISO Central Secretariat, and it’s now up to the ISO gods when it will be published. Based on past experience, it could be between a few weeks and a few months.
In this blog post, and probably one or more following ones, I want to discuss how collations in PostgreSQL work internally. See also this previous post about the work we have done for collations in PostgreSQL 15. And there is even more coming together in PostgreSQL 16 right now, which we will talk about in the future.
As some readers might be aware, in PostgreSQL, we have been working on adding a new build system using Meson. The new Meson build system has support for precompiled headers. I wanted to find out how useful that is.
If you are an application developer and you build on PostgreSQL, then maybe you have looked into where PostgreSQL comes from, who develops it, and where you can get professional help if needed.
Now, if you are a PostgreSQL developer (hi!), do you know what you are building on, where those things come from, who develops them, and where you get get professional help if needed?
I like to poke around the PostgreSQL Git repository to find interesting statistics and trends that affect PostgreSQL development. The question I had lately is, what are the largest patches that have been committed? That might indicate some kind of upper bound on the size of features you can get committed in one piece. If something is larger, you might need to split it up.
There is a PostgreSQL major release every year, and every release has about 200 changes listed in the release notes. A handful of those are typically listed at the top as “major items”, which are highlighted for the benefit of the public.
PostgreSQL development has certainly professionalized over the years, in the sense that more people do it as a job now rather than (only) as a hobby. I was wondering whether that would be visible in the time of day when people do publicly visible PostgreSQL work.
Let’s say you are following a patch in the PostgreSQL commit fest. The author has posted “v5” of a patch, some feedback has been sent, the author comes back with “v6” and a note saying that they have incorporated all that feedback. How do you check what actually changed?
I have been gathering some statistics about each major PostgreSQL release. Here is the update for this year:
Some time ago, someone asked on a PostgreSQL mailing list whether there was a diagram of the PostgreSQL system catalogs. There wasn’t at the time. Something like that used to be included in the PostgreSQL documentation, but it was never updated, and so it was eventually removed.
One of the new features in PostgreSQL 15 is that you can use ICU collations on a database and instance level.
A little while ago, we had a few PostgreSQL hackers in a room and someone oversaw me typing something like
I seem to be doing this a lot:
When you are coding in a source tree as big as PostgreSQL’s, you will at some point want to look into some kind of source code indexing. It’s often convenient not to bother, since
git grepis actually superfast. But when you want to find where a function is defined among all the call sites, some more intelligence is useful.
Here are some tweaks to
git logthat I have found useful. It might depend on the workflow of individual projects how applicable this is.
I was idly wondering what was taking
pg_dumpso long and noticed that it always seemed to be pegged at 100% CPU usage on the client. That was surprising because naively one might think that the bottleneck are the server’s or the client’s disk or the network. Profiling quickly revealed that the compression library zlib was taking most of the run time on the client. And indeed, turning compression off caused
pg_dumpto fly without getting anywhere near 100% CPU.
So I had this PostgreSQL database that was getting a bit too big, and since it was really only for analytics, I figured it would be a good fit for putting in Hadoop+Hive instead.
About two months ago, this happened:
PgBouncer has a virtual database called
pgbouncer. If you connect to that you can run special SQL-like commands, for example
2001: PostgreSQL 7.1: write-ahead log
There is a lot of helpful information about
screenout there, but I haven’t found anything about this. I don’t want to “forget” any screen sessions, so I’d like to be notified when I log into a box and there are screens running for me. Obviously, there is
screen -ls, but it needs to be wrapped in a bit logic so that it doesn’t annoy when there is no
screenrunning or even installed.
Normally, this doesn’t work as one might naively expect:
This is my new blog. My old blog was here, but it was time to move on.
subscribe via RSS