The last day of PGconf.dev 2024 Vancouver was an unconference. I’d never attended one of these before, so I was really curious to see how it would go.

Like I wrote about in the Day 1 notes, this conference is a little unusual because the audience is the developers of Postgres itself. These aren’t just users, database developers, or managers – these are the people writing the code for the database engine. The conference starts with a couple of days of sessions where developers talk about the goals they’d like to achieve in the next year, and Day 3’s unconference lets them self-organize into topics and groups based on the week’s inspirations.

Designing the Day’s Agenda

Day 3 started in the auditorium with people making pitches for patches.

As each person took the microphone to make their 15-30 second pitch, the audience gave quick feedback this triage whether the topic should be merged with another topic, or perhaps was too big to tackle in a single session.

After the submitted topics were merged down to 22, the audience voted to pick which ones would make it out of the 12 available slots, using shows of hands. When you raise your hand, you’re basically saying, “If there are no conflicts, I want to attend this session.” The 12 slots were to take place across 4 time windows, so you could really only attend 4 sessions, so you’d wanna raise your hand around 4 times out of the 22 potential topics.

The top-voted topics included multi-threading (the top vote getter), table am, protocol enhancements, observability, etc. Then the scheduling work started, taking the top 4 vote getters and putting them all in the big auditorium, then figuring out which sessions should be held opposite each main topic to minimize overlap. Topics that didn’t make the cut were encouraged to gather in the hallways.

Given that all of this was done with pieces of paper and group discussions, the rapid fire organization was pretty impressive, but then again, if there’s a group of people who could be trusted to quickly build an execution plan, filter, group, and sort things…. Yeah.

Watching the multi-threaded session

Since it was the top vote-getter, multi-threading went first up (10am) in the biggest room (the auditorium.) This was genius because people who needed to leave early could attend the most interesting session.

During the coffee break, before the session started, a couple of contributors grabbed a whiteboard and copied some talking points from a wiki post. They quickly brainstormed a list of work items that needed to be done, and wrote it up on a whiteboard. They analyzed it, and said, “These are the parts that we’d probably need to discuss, and these parts here just have mechanical work to be done.” They strategized how they wanted to run the discussion.

When the discussions started, they got deeply technical, quickly. Between the room, it felt like everyone had all of the Postgres source code in memory, so they were able to efficiently make quick progress on big picture challenges. All of it was wildly over my head, but it was fun to watch the brainstorming.

After about 35 minutes of technical discussions about individual issues, the talk turned to scheduling. Multithreading as a whole is too much to ship all at once, obviously, and some of the work needed to be done first to prepare for other parts of the work. Finally, they discussed which committers would agree to shepherd each of the main areas of work.

It felt like there was a bit of a plan forming, and progress would be made.

Observability session

I was going to head out to the airport, but I ran into Jeremy Schneider of AWS, and he was part of the team running the next auditorium session – observability. That’s a topic I love passionately, so I stuck around.

Jeremy recapped feature requests included plan hashes, queries per second counters, low-level traces of what happens during a query’s execution, and OpenTelemetry integration. Other community members talked about what databases need in order to become self-driving, so to speak – automated query tuning, index management, vacuum management, a built-in equivalent of OtterTune, etc.

The observability session was an interesting contrast to the multi-threading session:

• The multi-threading session had a simple easy-to-understand goal, so the discussion was about how to accomplish that goal
• The observability session didn’t have a clear goal, so the discussion was about what the final goal should look like

People wanted all kinds of different things:

• Some people just wanted to expose new metrics that aren’t available today
• Some wanted aggregation & reporting on those metrics
• Some wanted observability of a system that was in the midst of crash recovery to understand how long it’d take (when system tables weren’t even available yet)
• Some wanted the functionality in core, and some thought it was better suited for extensions

Jeremy kept asking, “So what should we do next?” As in, what’s a step we could actually take and make the user experience better?

Overall thoughts

Unconference sessions continued through the day, but I headed to the airport to catch an earlier flight home. I’d learned enough about how the sausage is made, and sitting in more technical unconference sessions wouldn’t help me.

Overall, I was really impressed by PGConf.dev. If I was a developer who wanted to begin contributing to Postgres, or if I was an architect at a company that was deeply reliant on Postgres, I would totally come back every year. I don’t fall into either of those categories, though – I just attended because I was intellectually curious – and I was really happy with my experience.