Monday, February 18, 2019

Tuning autovacuum_naptime

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

How Much maintenance_work_mem Do I Need?

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

Who Contributed to PostgreSQL Development in 2018?

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

Amazon's DocumentDB, MongoDB, and TechCrunch

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.