Candidate Materials — Dongpo Liu
Overview
Thank you for taking the time to review my materials.
This document collects several samples of my work, writing, analysis, and presentations. For each sample, I have included a short description of the context and why I selected it.
1. Work Samples
Work Sample 1: Auto Analyze Priority Queue
Link: Auto Analyze priority queue implementation
Context: I implemented a priority-based scheduling mechanism for automatic table statistics collection in the database background worker system. The scheduler was designed to keep table statistics fresh while avoiding starvation and preventing small, frequently updated tables from dominating the queue.
This work was important because statistics are a critical input to the query optimizer. Accurate and timely statistics improve cardinality estimation, cost estimation, and the overall quality of query plan selection.
Why I selected this sample: This is one of the most important projects I have delivered at PingCAP. I have been iterating on this module for almost three years, improving its correctness, reliability, and maintainability over time as production requirements evolved.
Outcome:
- Improved the fairness and efficiency of auto-analyze scheduling, significantly reducing table starvation.
- Eliminated the overhead of repeatedly rebuilding the priority queue by keeping it in memory, reducing CPU usage by approximately one core and lowering memory consumption by 99%.
Notes:
The writing samples provide additional design context for this implementation.
Work Sample 2: cargo info Command
Link: cargo info pull request
Context: This project closed a 10-year-old Cargo issue by introducing a new subcommand, cargo info, which allows users to inspect Rust package information directly from Cargo.
I designed and developed the feature together with Ed. The project reflects my deep involvement in Cargo: after contributing to Cargo for about five years, I was invited to join the Cargo team, and I have now been contributing to the project for around seven years.
Why I selected this sample: I selected this sample because it is one of the largest and most important features I have delivered in Cargo. The work happened in a fully open-source environment, where Cargo has high standards for code quality, documentation, review, and collaboration.
This project demonstrates my ability to work effectively outside my usual professional environment and to deliver a high-quality feature in a mature and widely used open-source project.
Impact: The feature has since been merged into Cargo as an official subcommand, where it is used by developers as part of their everyday workflow.
2. Writing Samples
Writing Sample 1: RFC: Priority Queue for Auto Analyze
Link: Priority Queue for Auto Analyze RFC
Context: This RFC proposed introducing a priority queue for automatic statistics collection in TiDB. It was my first RFC after joining the optimizer team.
The design went through a long iteration process, including multiple rounds of internal discussion, before we converged on the final approach. For the corresponding implementation, please refer to Work Sample 1.
Why I selected this sample: I selected this sample because it was my first RFC after joining the optimizer team. It required me to learn a new codebase, understand the existing design constraints, and collaborate closely with new teammates.
The RFC went through many rounds of discussion and iteration. I used that process not only to improve the design, but also to build trust and working relationships with the team.
Writing Sample 2: RFC: Maintain The Priority Queue In Memory
Link: Maintain the Priority Queue in Memory RFC
Context: This RFC was a follow-up iteration on Writing Sample 1. After the initial priority queue design was implemented, we encountered new customer requirements that made it necessary to avoid rebuilding the queue repeatedly. Re-scanning millions of table objects over and over again was too expensive.
The main challenge was maintaining the priority queue in memory while handling DDL events correctly. I worked with a colleague from the DDL team to design a solution that kept the in-memory queue consistent as table metadata changed.
Why I selected this sample: I selected this sample because it shows how the original design evolved over time. Writing Sample 1 left one important problem unresolved: how to maintain the priority queue in memory to avoid repeatedly rescanning all tables and rebuilding the queue. About a year later, we revisited that problem and delivered a follow-up design.
What I like about this work is that it did not require breaking the previous design. Instead, it demonstrated that the original design was extensible enough to support the new requirement. The hardest part was reasoning clearly about DDL ordering and keeping the in-memory queue consistent as table metadata changed.
This work also required close collaboration with the DDL team, making it a good example of cross-team design and delivery.
3. Analysis Samples
Analysis Sample 1: Memory Leak
Link: TiDB memory leak RCA
Context: I investigated a customer-reported TiDB memory leak in the asynchronous statistics-loading path, reproduced the issue by forcing histogram-loading failures, and helped narrow it down to resource cleanup problems in the error-handling path.
Problem statement: In the customer’s production environment, TiDB’s memory usage kept increasing. However, we did not have access to the customer’s actual workload. This made it difficult to identify the root cause from the available observability data.
Approach: Because the available observability data did not provide enough clues, I investigated the issue by tracing the relevant code path line by line. Although I was not very familiar with this part of the codebase at the time, I used the limited signals we had: the customer had changed the tidb_opt_objective parameter, and there were error logs related to statistics loading.
I started from the code path where tidb_opt_objective is set, then followed how it affects optimization behavior and statistics loading. This eventually allowed me to reproduce the same error logs and memory growth locally.
Why I selected this sample: I selected this sample because it reflects a debugging approach I value highly: carefully reading the code until the system behavior becomes understandable. This investigation happened before AI-assisted coding tools were part of my regular workflow, so I had to trace the relevant paths manually, line by line.
That process eventually revealed the clues needed to reproduce the issue. It reinforced my belief that, for difficult system problems, the source code is often the most reliable source of truth.
Analysis Sample 2: AI-Assisted RCA for a Seven-Year-Old Bug
Link: Seven-year-old statistics update bug RCA
Context: TiDB’s statistics modify_count could fail to update after DML; even after inserting a new row into an analyzed table, SHOW STATS_META could still report Modify_count = 0, which could make table-change tracking inaccurate and affect auto-analyze decisions.
Problem statement: In the customer’s production environment, a table received a large number of updates, but TiDB failed to record those changes in its internal statistics metadata. Since this metadata is used to decide when table statistics should be refreshed, the table could incorrectly appear unchanged.
Although TiDB periodically flushes table modification information every five minutes, the update count was never persisted in this case.
Approach: We encountered this issue at least twice. The first time, we were not able to identify the root cause. The second time, we still struggled at first, partly because we assumed that the five-minute forced flush mechanism was reliable: it had been in the codebase for about seven years, so we naturally believed it was working correctly.
Because of that assumption, I spent a lot of time reading other parts of the code while initially overlooking this old mechanism. After I still could not find the problematic code path, I went back to collect more information and used AI to help me inspect the code more systematically.
It turned out that the code path I had assumed to be correct had actually never worked properly for the past seven years. Once I realized that this mechanism was not trustworthy, I was able to reproduce the issue, identify the root cause, and fix it.
Why I selected this sample: I selected this sample because it shows another way I approach root-cause analysis. My first instinct was to read the code carefully myself, but in this case, AI tools turned out to be extremely useful for exploring the code quickly and without the assumptions I had developed from working on this system every day.
This was one of the first moments where I felt that collaborating with AI materially improved my debugging process. It was also the first real on-call issue I solved with significant help from AI-assisted code exploration.
4. Presentation
Presentation Sample 1: Shipping TiKV with Cargo
Link: Recording: Shipping TiKV with Cargo recording
Slides: Shipping TiKV with Cargo slides
Context: This was a presentation I gave at Rust Munich 2026. In the talk, I shared practical knowledge about Cargo and explained how we use Cargo to manage and ship a complex production project.
Why I selected this sample: I selected this sample because it was my first in-person technical talk in English. Although I had given many internal and online technical presentations before, delivering a talk in person was a new challenge for me.
It was personally meaningful, and it also gave me an opportunity, as a Cargo maintainer, to share practical knowledge and real-world lessons with the Rust community.
Presentation Sample 2: TiDB Analyze
Link: Recording: TiDB Analyze recording
Slides: TiDB Analyze slides
Context: This was a presentation I first gave internally and later shared publicly. It explains TiDB’s ANALYZE feature and walks through the full workflow of the module.
I prepared this talk about one year after joining the team. At the time, I wanted to build a deeper understanding of the system, so preparing the presentation was also a learning process for me. I used demos and animations to make the internal workflow easier to understand and to explain how each component fits together.
Why I selected this sample: I selected this sample because it reflects how I often learn: by teaching. Preparing a talk forces me to understand a system deeply enough to explain it clearly to others.
This presentation was also a summary of my first year working on TiDB statistics. During that time, I tried to build a deep understanding of the system, continuously identify issues, and develop a clearer sense of what mattered most and where the system needed to improve.
5. Summary
The materials above are intended to show how I approach engineering work: understanding complex systems, communicating trade-offs, debugging production issues, writing maintainable software, and collaborating with others.
Thank you again for reviewing them.