You probably know that PostgreSQL is well-supported by its active community. You may also be aware that PGCon is the annual conference for PostgreSQL users and developers. You may not know that PGCon conducts 'unconferences' that deploy an excellent transparent voting system to decide the topics that potentially guide future features in PostgreSQL.
So let's start with PGCon 2018. This was the most recent PGCon and one that I only recently attended in beautiful Ottawa in Canada.
It's a venue where we PostgreSQL people get a chance to meet, discuss issues and opportunities, build new relationships with people from around the world, gain insights, and discuss the work we are all doing with PostgreSQL.
I thought I'd share another excellent part of the event that seems to have a potentially significant impact on the feature set and quality that we have come to expect in PostgreSQL these days.
They are called unconferences.
I experienced my first one at PGCon 2018.
Unconferences are a participant-driven discussion regarding a wide range of topics. The critical thing is, these topics are decided just before starting the talks. Thus the 'un' in 'unconference'.
They provide an excellent environment to brainstorm and collaborate on potential new features or sound new solutions to current challenges. Stephen Frost coordinated the session pitches and scheduling phase on Wednesday morning. This was an active process that was carried out with both enthusiasm and good humour.
A large number of topics were proposed by various attendees covering areas such as:
- Review of monitoring metrics and known gaps
- User logging and autonomous transactions
- Removal of SLRU and moving to buffer cache
- JIT compilation - which areas to look at first
- General High Availability
- Pluggable table access methods
- Multi master in core postgres
- Table level TDE
- Undo logs – storage layer
- Query optimisation for partitioned tables
- Versioning of extensions and improving hooks
- Global snapshots
- Scaling out PostgreSQL
- Schema deployment and the best approach for PostgreSQL
- Decoupling front end from backend processes
- Redesigning the query executer
- Multi process and multi threading
Here's how it works
- Big Post-it Notes (I mean, colossal Post-it notes)
Ideas are written on large Post-it notes and stuck on the wall. The topic proposer outlines a description of the topic to everyone in attendance. When all proposed subjects have had any uncertainties clarified, the number of topics are reduced to fit the number of available sessions. This was 16 at PGCon 2018. - Merging of Topics
Similar topics are examined to see if they are a good candidate for merging. The topic proposer then has the opportunity to accept or reject the merging. You can see this is a very thoughtful and democratic process. - Let's Vote
Once merging is complete, a voting process begins. Every attendee votes through a raise of hands for each topic they wish to see discussed. The votes are totalled and written on the associated Post-it note, and then the 16 topics are selected based on the highest number of votes. The remainder are discarded for this unconference. The voting system is also used to allocate topics to rooms and help reduce conflicts where popular topics are run concurrently.
At PGCon 2018, the most popular topics included:
- global snapshots/scale out
- redesign query executor
- pluggable table access methods
- JIT compilation
- with 'monitoring' and 'decoupling front from backend' coming in next.
Through such a transparent and democratic process, you can see an indication of the areas of interest and as such the potential for new features in PostgreSQL (although there are never any guarantees as positive feedback given by the community during the sessions is not to be taken as approval or agreed direction for a particular topic or feature). It's important to note that you need to submit your feature request and have it approved in the normal way to guarantee a feature inclusion.
Thank you to everyone who attended PGCon 2018. I look forward to seeing you next year.