Projects
Database systems, PostgreSQL extensions and planner experiments.
Two threads run through this page. Logical replication is what I am paid to work on — currently Spock at pgEdge. The planner and executor are what I work on as a PostgreSQL contributor, and they account for everything under core, the extensions in my own account, and the experiments at the bottom.
Published regularly
DBMS Digestlive
"Signal over sales" — a weekly roundup of what actually happened in PostgreSQL and the wider database world: new features and internals, threads worth reading on pgsql-hackers, -bugs and -performance, community arguments, migration case studies, techniques borrowed from SQL Server, Oracle, MySQL and OceanBase, and academic work. Fifteen to twenty-five curated links an edition, no marketing, written for people who work on database internals rather than for buyers. Generated rather than hand-assembled — the reasoning behind that is in the blog post below.
In PostgreSQL core
Self-Join EliminationPostgreSQL 18
Drop a self-join from the query tree when a single scan provably returns the same rows. Committed for 17, reverted, redesigned and committed again for 18; the RowMark and placeholder edge cases that caused the revert are fixed in the version that shipped.
OR-clause to array transformationPostgreSQL 18
Turn a long chain of OR'd equality tests into a single ScalarArrayOpExpr, so the planner can match it to an index or a bitmap path instead of walking the chain. Also reverted once before landing.
GROUP BY key reorderingPostgreSQL 17
The optimizer is free to choose the order of grouping columns; ordering them to cut comparison work is now a costed choice, controlled by enable_group_by_reordering.
Extended statistics for hash join bucket sizePostgreSQL 18
Use multivariate statistics to estimate hash join bucket size, instead of assuming independence between the hash keys.
Tuple-bound propagation through AppendPostgreSQL 18
Teach Append to take the query's tuple fraction into account when accumulating subpaths, so a LIMIT above a partitioned scan is not planned as though every partition would be read in full.
PG_MODULE_MAGIC_EXTPostgreSQL 18
An extension can now declare its name and version in the module magic block, so the server knows what it loaded rather than inferring it.
WAL volume reduction in index buildsPostgreSQL 12
Generate less write-ahead log while building GiST, GIN and SP-GiST indexes, and drop an unnecessary copy when reading a WAL record that fits on one page.
Extensions
Spockopen source
Logical multi-master replication for PostgreSQL. Work here covers active-active replication across clusters and an architectural redesign that removed the extension's dependency on patches to core Postgres.
Adaptive Query Optimizer (AQO)open source
Database systems usually process queries of quite similar structure. The idea is to save information about the actual number of rows produced by query plan nodes and reuse it during the next execution. Two significant hurdles were managed here: node signatures had to be invented to match cardinalities to specific nodes during planning, and the knowledge base had to be generalized.
pg_track_optimizeropen source
A lightweight PostgreSQL extension designed to identify poorly optimized queries — spotting planning problems before they show up as a performance incident.
pg_middleoutearly stage
Middle-out planning: a top-down pass added after the planner's usual bottom-up phase. Its first use is memoizing correlated subqueries. A correlated subquery that cannot be pulled up into a join becomes a SubPlan that re-executes for every outer row, and core PostgreSQL only attaches Memoize to parameterized nested loops, never to a SubPlan — so repeated parameter values are recomputed, which ORM-generated SQL does constantly. The reason core cannot fix this in place is a chicken-and-egg problem: a SubPlan is built during the parent query's expression preprocessing, before the parent's own paths exist, so neither execution frequency nor the distribution of parameter values — both needed to cost a Memoize — is known yet. Both are available once upper-query planning has finished, which is where this extension hooks in, walks the cheapest path tree, and swaps in a memoized subplan when it pays for itself.
pg_index_statsopen source
Computing multivariate statistics automatically for every combination of columns is impractical. The conjecture is that index structure already tells you which column sets are most frequently used for extracting data, and those are exactly the ones that matter for building good plans.
Query plan freezing (sr_plan)open source
Freeze a query plan and reuse it, instead of letting the planner reconsider the query on every execution. Design, pitfalls and lessons learned were presented at the Israeli PostgreSQL Jam in 2023.
Systems
Shardmanproprietary
A distributed database system built natively on PostgreSQL. The fundamental conjecture is that the standard foreign data wrapper technique, as implemented in postgres_fdw, can be enough to partition data across multiple servers. The main efforts went into distributed timestamp-based transactions (CSN), optimizer extensibility, and the must-have features for distributed execution — global tables, asymmetric join, shuffle join. I was the architect of the project, and proposed and prototyped substantially all of the query optimization and distributed execution features it runs on today. The code is proprietary; the design is public in the talks and the mailing-list thread below.
Multimasteropen source
Built-in high availability for PostgreSQL, leveraging a global transaction ID and logical replication. From the application's standpoint all servers hold equivalent data up to MVCC, with automatic conflict resolution. The trade-offs: transactions default to REPEATABLE READ isolation, and DML performance degrades as instances are added. The distance between servers is bounded only by network speed and the internal heartbeat timeout.
Omega — parallel DBMS for cluster systemsarchived
The subject of the Ph.D. work: query processing in a parallel DBMS for multiprocessor systems with a hierarchical architecture. Introduced a data placement and partial-mirroring strategy, and a load balancing method for parallel query execution on clusters.
Enterprise forks and experiments
Not in PostgreSQL itself: techniques built for an enterprise fork, and optimizer ideas explored as prototypes. Patches currently open upstream are tracked separately, on the in flight page.
Asymmetric join
Oriented mostly at distributed execution. Works much like the partitionwise join feature, but allows a plain table to be joined with a partitioned one.
Switch Join
An adaptive join that stops betting everything on the planner's cardinality estimate. Two plans are prepared up front — an optimistic one, typically a nested loop, and a pessimistic fallback, typically hash or merge join. During execution outer tuples are materialized while actual row counts are watched; once the count crosses a threshold, execution switches to the pessimistic plan mid-flight, reusing the already-materialized data without a restart or a replan. Author and lead developer, with A. Rybakina, who presented the work at PGConf.Spb 2024 and pgconf.dev 2025. The source is not public.
Query re-optimization
Detect at run time that a plan has gone hopelessly wrong and replan the query instead of waiting for it to finish. Designed and implemented for the Postgres Pro enterprise fork; presented at PGConf.Russia 2023.