Robert M. Haas

Vice President, Chief Database Architect, EDB

Robert Haas is a PostgreSQL major contributor and committer. PostgreSQL features which he has authored or coauthored include unlogged tables, fast-path locking, index-only scans, and parallel query. PostgreSQL features written by others which he has reviewed and committed include table partitioning, logical decoding, event triggers, and foreign tables. He works at EnterpriseDB as VP, Chief Database Scientist.

Prior to working at EnterpriseDB, Robert worked as a web application developer for almost 10 years. He first became interested in PostgreSQL development after running up against limitations of the PostgreSQL query optimizer during one of those jobs, specifically the inability of the optimizer to consider join removal. At EnterpriseDB, he has worked mostly on PostgreSQL, but also at times as a member of the support organization, and at other times on EnterpriseDB's Advanced Server, Backup and Recovery Tool, and Postgres Enterprise Manager products.

Read Blogs

EDB Labs

Surviving Without a Superuser: Coming to v16

One way that you can make a PostgreSQL role very powerful is to give it the CREATEROLEproperty, either by creating it using a command like CREATE USER alice CREATEROLE, or by adding that property later using a command like ALTER ROLE alice CREATEROLE. Unfortunately, in existing releases, that's both too much and not enough.
Postgres Tutorials

History of improvements in VACUUM in PostgreSQL

In a recent blog post, I talked about why every system that implements MVCC needs some scheme for removing old row versions, and how VACUUM meets that need for PostgreSQL. In this post, I’d like to examine the history of VACUUM improvements in recent years, the state of VACUUM as it exists in PostgreSQL today, and how it might be improved in the future.
Postgres Tutorials

Using force_parallel_mode Correctly in PostgreSQL

I admit it: I invented force_parallel_mode. I believed then, and still believe now, that it is valuable for testing purposes. Certainly, testing using force_parallel_mode=on or force_parallel_mode=regress has uncovered many bugs in PostgreSQL's parallel query support that would otherwise have been very difficult to find.
Postgres Tutorials

Why we need VACUUM to implement MVCC In PostgreSQL

Experienced PostgreSQL users and developers rattle off the terms “MVCC” and “VACUUM” as if everyone should know what they are and how they work, but in fact many people don’t.

Amazon's DocumentDB, MongoDB, and TechCrunch

Over on TechCrunch, you can find an article posted just yesterday with the inflammatory title AWS gives open source the middle finger. The premise of the article is that, by creating a product which aims to provide compatibility with MongoDB, Amazon is attacking open source. This is a false narrative. MongoDB recently relicensed its code in such a way that it can no longer be used by cloud...
EDB Labs

Parallelism and Partitioning - Improvements in Postgres 11

There have been a number of articles on the upcoming improvements in Postgres v11, including one by EnterpriseDB’s own Bruce Momjian. A couple of the most commonly highlighted areas are in parallelism and partitioning.
EDB Labs

Using force_parallel_mode Correctly

I admit it: I invented force_parallel_mode. I believed then, and still believe now, that it is valuable for testing purposes.
EDB Labs

Built-in Sharding for PostgreSQL

Built-in sharding is something that many people have wanted to see in PostgreSQL for a long time. It would be a gross exaggeration to say that PostgreSQL 11 (due to be released this fall) is capable of real sharding, but it seems pretty clear that the momentum is building. The capabilities already added are independently useful, but I believe that some time in the next few years we're going to...

DO or UNDO - There is no PostgreSQL VACUUM

What if PostgreSQL didn’t need VACUUM at all? This seems hard to imagine. After all, PostgreSQL uses multi-version concurrency control (MVCC), and if you create multiple versions of rows, you have to eventually get rid of the row versions somehow. In PostgreSQL, VACUUM is in charge of making sure that happens, and the autovacuum process is in charge of making sure that happens soon enough. Yet...

The State of VACUUM

In a recent blog post, I talked about why every system that implements MVCC needs some scheme for removing old row versions, and how VACUUM meets that need for PostgreSQL. In this post, I’d like to examine the history of VACUUM improvements in recent years, the state of VACUUM as it exists in PostgreSQL today, and how it might be improved in the future. When I first began using PostgreSQL...