If you want to learn more about Citus on Microsoft Azure, read this post about Hyperscale (Citus) on Azure Database for PostgreSQL.
About once a month I get this question: “How do I contribute to Postgres?”. PostgreSQL is a great database with a solid code base and for many of us, contributing back to open source is a worthwhile cause. The thing about contributing back to Postgres is you generally don’t just jump right in and commit code on day one. So figuring out where to start can be a bit overwhelming. If you’re considering getting more involved with Postgres, here’s a few tips that you may find helpful.
Follow what’s happening
The number one way to familiarize yourself with the Postgres development and code community is to subscribe to the mailing lists. Even if you’re not considering contributing back, the mailing lists can be a great place to level up your knowledge and skills around Postgres. Fair warning: the mailing lists can be very active. But that’s ok, as you don’t necessarily need to read every email as it happens—daily digests work just fine. There is a long list of mailing lists you can subscribe to, but here are a few I think you should know about:
- pgsql-general - This is the most active of mailing lists where you’ll find questions about working with Postgres and troubleshooting. It’s a great place to start to chime in and help others as you see questions.
- pgsql-hackers - Where core development happens. A must read to follow along for a few months before you start contributing yourself
- pgsql-announce - Major announcements about new releases and happenings with Postgres.
- pgsql-advocacy - If you’re more interested in the evangelism side this one is worth a subscription.
Following along to these lists will definitely prepare you to contribute code in the future. And will give you the opportunity to chime in to the discussions.
Familiarize yourself with the process
As you are reading along with the mailing lists the docs will become one of your best friends for understanding how certain things work. Postgres docs are rich with how things work so when you have questions best to check there ahead of asking what may have already been answered. Different areas may be slightly different to contribute to, it can range from docs improvements to bug fixes to new features. The PostgreSQL wiki has its own guide to help prepare you for contributing.
So you think you want to contribute?
You’ve read the mailing lists, you’ve chimed in to some discussions, you’re ready. But where to begin?
One of the best places is to help with code review of open patches during a commitfest. You see, development happens in sprints (known as commitfests) for Postgres. Within the commitfest app you can browse the various commitfests, browse open patches, and review/comment on them. Often just as much work can go into review of patches as there is in writing them, so contributing on review and testing can be extremely helpful.
You’ve reviewed some patches, you’re ready to write your own
Before you just jump right in and write a patch it can be good to test the waters. Consider starting back at step one with a discussion on the mailing list. Lay out the problem you see and that you’re interested in helping to fix it. Sometimes someone else may already be working on it, or may see dangers in that area, or just maybe the mailing list is overwhelmingly on board and looking forward to your patch. What you picked up from following the mailing lists and reviewing patches already should do you well as you start to dig in. Then once it is written submit it during and open commitfest.
Code isn’t the only way
Yes, Postgres is code and at heart it is a database. But it is more than that, it’s a community. Postgres doesn’t work on code alone, it works from people sharing their knowledge on it and helping others. If you don’t feel quite ready to jump in and contribute, there are plenty of opportunities to give back such as joining your area non-profit to support evangelism efforts: PostgreSQL.US in the US, and PostgreSQL EU in Europe. You can also yourself start blogging about Postgres (if you do register your blog for PostgreSQL Planet) or consider speaking at your nearby user group.
Not everyone will be a PostgreSQL developer, but that doesn’t mean you can’t follow along and participate. If you just want to lurk that’s perfectly fine. Consider subscribing to Postgres Weekly or the Citus newsletter and follow on twitter @postgresql.