Recently, the PostgreSQL project spun up a "contributors" team, whose mission is to ensure that the PostgreSQL contributors list is up-to-date and fair. The contributors page has a note which says "To suggest additions to the list, please email email@example.com." The current members of the team are Dave Page, Stephen Frost, Vik Fearing, and me.
Wednesday, June 05, 2019
Monday, February 18, 2019
One of the things I sometimes get asked to do is review someone's postgresql.conf settings. From time to time, I run across a configuration where the value of autovacuum_naptime has been increased, often by a large multiple. The default value of autovacuum_naptime is 1 minute, and I have seen users increase this value to 1 hour, or in one case, 1 day. This is not a good idea. In this blog post, I will attempt to explain why it's not a good idea, and also something about the limited circumstances under which you might want to change autovacuum_naptime.
Thursday, January 24, 2019
While I generally like PostgreSQL's documentation quite a bit, there are some areas where it is not nearly specific enough for users to understand what they need to do. The documentation for maintenance_work_mem is one of those places. It says, and I quote, "Larger settings might improve performance for vacuuming and for restoring database dumps," but that isn't really very much help, because if it might improve performance, it also might not improve performance, and you might like to know which is the case before deciding to raise the value, so that you don't waste memory. TL;DR: Try maintenance_work_mem = 1GB. Read on for more specific advice.
Wednesday, January 23, 2019
This is my third annual post on who contributes to PostgreSQL development. I have been asked a few times to include information on who employs these contributors, but I have chosen not to do that, partly but not only because I couldn't really vouch for the accuracy of any such information, nor would I be able to make it complete. The employers of several people who contributed prominently in 2018 are unknown to me.
Thursday, January 10, 2019
Over on TechCrunch, you can find an article posted just yesterday with the inflammatory title AWS gives open source the middle finger. The premise of the article is that, by creating a product which aims to provide compatibility with MongoDB, Amazon is attacking open source. This is a false narrative. MongoDB recently relicensed its code in such a way that it can no longer be used by cloud providers without paying license fees to MongoDB. In essence, then, TechCrunch is claiming that because Amazon is choosing to run code for which they don't have to pay license fees instead of code for which they do have to pay license fees, they're attacking open source.
Thursday, June 21, 2018
I admit it: I invented force_parallel_mode. I believed then, and still believe now, that it is valuable for testing purposes. Certainly, testing using force_parallel_mode=on or force_parallel_mode=regress has uncovered many bugs in PostgreSQL's parallel query support that would otherwise have been very difficult to find. At the same time, it's pretty clear that this setting has caused enormous confusion, even among PostgreSQL experts. In fact, in my experience, almost everyone who sets force_parallel_mode is doing so for the wrong reasons.
Friday, June 01, 2018
Last year, I wrote a post on who contributed to PostgreSQL development in 2016. This is a (belated) version of the same information for 2017. I used the same methodology this time for analyzing the commit log as I did last year.