Alena Rybakina: “The path to becoming a PostgreSQL committer starts with your first review”

We’re starting a series of articles about Postgres Professional engineers who received awards for their contributions to the PostgreSQL community. In this interview, core developer Alena Rybakina explains how to start contributing and where it can take you.

— Alena, what did you receive the medal for?
— For reviewing a large number of patches. I would pick them up during CommitFests, test how they behaved, and leave feedback. Sometimes it was just about adding tests. In other cases, I found edge cases, regressions, or scenarios that hadn’t been considered.

Later, I started working on a major patch of my own — OR-ANY Transformation. Let me explain what it does.

The problem it addressed was inefficient planner behavior when handling multiple OR conditions on the same column. Before this patch, the PostgreSQL optimizer would typically execute a separate Bitmap Index Scan for each OR clause. That meant scanning the same index pages multiple times instead of walking them once.

My patch transforms such queries into a more efficient Index Scan, or Index Only Scan, that traverses the index pages just once and filters the required values during the scan itself. The work took about a year, but eventually the patch was accepted and committed to PostgreSQL 17.

— Alena, how did the optimizer patch come about? Did it grow out of a review, or was it triggered by a real-world issue?
— It actually started with a customer case. Their framework didn’t support IN operators, so queries with multiple conditions on the same column were generated as long chains of OR clauses.
In principle, this should have been handled with IN. The real challenge, though, was the scale. The framework was generating around 50,000 OR conditions for a single column. During planning, such a query could consume about 1.5 GB of memory and eventually be killed by the operating system.

At first, it felt like a somewhat artificial problem. The root cause was clearly in the framework rather than in PostgreSQL itself. The customer eventually resolved the issue by switching frameworks and didn’t wait for the patch. Still, we found the problem interesting enough to continue working on it. While discussing the patch on the mailing list, I received a reply from Peter Geoghegan, who shared a related project he had been working on. That turned out to be closely connected to my approach. We eventually completed the patch, and the community accepted it. So in a sense, the problem appeared almost by accident, but it led to a meaningful improvement in the planner.

— Why did you decide to start reviewing patches in the first place?
— There wasn’t any special initiative behind it. I knew I needed to do reviews to improve my skills.
What really pushed me was my former colleague Andrey Lepikhov, who is an active PostgreSQL contributor. He believes that one of the best ways to grow as an engineer is to study how other developers write and structure their patches.

What Andrey Lepikhov was recognized for
Like Alena, Andrey received a medal for his contributions to the community. He identified a bug in the PostgreSQL codebase while working with his colleague Nikolay Shaplov to test hypotheses around fuzzing autonomous transactions. The issue appeared to have existed for quite some time, but for various reasons had not been addressed. Thanks to this finding, Tom Lane was able to close one of the vulnerabilities in PostgreSQL.

At first, it was really difficult. I didn’t know what to look for, what to comment on, or even where to start. But after a while, things began to fall into place. Now I try to do reviews as often as I can, although my main job doesn’t always leave enough time for it. It’s a great way to improve your skills and make your name known in the community.

— In your view, what makes a “good” patch that gets through review quickly?
— It really depends on the type of patch. Broadly speaking, there are three main scenarios:

1) A bug fix. Usually the fastest path. The key points are:

• Make sure the code style is correct. Comments should be properly placed and clearly explain why a particular line was added, modified, or removed. The commit message should describe the problem clearly and explain how the patch resolves it.
• Add regression tests that demonstrate the issue. Ideally, the tests should fail without the patch and pass with it. This helps prevent others from reintroducing the same bug later. In some cases, adding a test is not feasible, for example if the bug is related to abnormal memory consumption. Reviewers understand that. But if a test can be written, it should be included.
• Ensure the patch does not introduce regressions.

2) A new feature. This is the most complex and time-consuming path, as it was with my OR-ANY Transformation.

• You need to prove that your feature does not break anything. That means extensive testing. You should demonstrate that it behaves correctly with complex plans, multiple JOINs, user-defined operators, and that it does not interfere with existing optimizations. Query results must remain identical with and without the patch.
• Be prepared for a long review cycle. Reviewers will deliberately try to break your patch and uncover edge cases you may have missed. That is a good thing. The more people look at your code, the lower the risk of post-commit issues. Even in our case, after the patch was committed, we still discovered an unpleasant bug that had slipped through.

3) Documentation. This is the simplest path. You spot an issue in the documentation and propose a fix. There is no code involved, so the review process is usually straightforward and relatively quick. Reviewers may suggest wording changes or clarifications, but those are minor compared to code reviews.

— Alena, what would you advise developers who want to start reviewing patches?
— My advice is based entirely on personal experience:

• Dive deep into a specific area. I focused on my domain — the query optimizer — and looked for every available resource to understand it thoroughly.
• Just start. I knew I wasn’t 100% ready, but I still picked a patch that interested me and began digging into it: understanding the problem and evaluating the proposed solution.
• Start small. Documentation patches are often the easiest entry point. They help you understand how things are structured internally, and reviewing them is already a meaningful contribution.
• Don’t be afraid of small steps. Even if your feedback is just an email to the mailing list suggesting an improvement to a code comment, that is still a valid contribution.
• Be patient. A finished patch may wait some time before being committed. Committers can be busy with higher-priority issues, such as critical production bugs. That is a normal part of the process.

The most important thing is to pick a patch, sit down with it, understand what it does, and send an email with your thoughts.

As Lao Tzu said, a journey of a thousand miles begins with a single step. The path to becoming a PostgreSQL committer begins with your first review.