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

A few weeks ago, Josh Berkus wrote a blog post on Why HStore2/jsonb is the most important patch of 9.4. Everybody's going to have their own opinion on these kinds of questions, but for what it's worth, I think the most important new feature in 9.4 is going to turn out to be logical decoding, the result of a lot of hard work mostly by Andres Freund.
Yesterday, Heikki Linnakangas committed this patch: commit a3115f0d9ec1ac93b82156535dc00b10172a4fe7 Author: Heikki Linnakangas Date: Wed Mar 12 22:46:04 2014 +0200 Only WAL-log the modified portion in an UPDATE, if possible. When a row is updated, and the new tuple version is put on the same page as
EDB Labs
In two weeks, I'm headed to LSF/MM and the Linux Collaboration Summit, by invitation of some Linux kernel hackers, to discuss how the Linux kernel can better interoperate with PostgreSQL. This is good news for PostgreSQL, and hopefully for Linux as well. A post from Mel Gorman indicates that this topic is attracting a lot of interest, and that MariaDB and MySQL developers have now been invited to...
There's a persistent belief among some users of PostgreSQL that VACUUM and VACUUM FULL do the same thing, but that VACUUM FULL does it better. If VACUUM is the moral equivalent of running the Dust Buster across the room a few times, VACUUM FULL must be the equivalent of hiring a professional cleaning crew to shampoo the carpets, and maybe repaint the walls as well. Unfortunately, this mental model is not accurate.
EDB Labs
For the last several months, I have been spending a large percentage of my time trying to bring parallelism to PostgreSQL.
EDB Labs
I spend a lot of time answering questions about PostgreSQL, and one of the questions I get asked frequently is: how should I set shared_buffers? And, a bit less often, how should I set wal_buffers? I've got canned answers that I can rattle off so fast it'll make your head spin. Exceptions to my canned answers keep popping up, and it's starting to get hard to give an answer that actually captures all the complexity in this area, so here's a longer explanation.
EDB Labs
Over the years, I've occasionally encountered situations where VACUUM fails to make progress, and not fully understood why that was happening. Recently, I've come to a better understanding of how lock conflicts can result in VACUUM stalling out either at the beginning of the table, or part-way through.
EDB Labs
Almost two months ago, I wrote part one of what I indicated would be an occasional series of blog posts comparing the architecture of PostgreSQL to that of MySQL. Here's part two.
Have you ever had one of those annoying problems where a query, or some kind of maintenance task such as vacuum, seems to hang, without making any discernable foreign progress, basically forever? If it's a foreground task, you typically think to yourself "oh, that's taking longer than normal" - but then you start to become suspicious as to whether anything's happening at all. You fire up top, or...
EDB Labs
In a recent blog post on Gigaom, Simeon Simeonov argues that virtualization is on the way out, and discusses VMware's move toward platform-as-a-service computing. In a nutshell, his argument is that virtualization is inefficient, and is essentially a last resort when legacy applications can't play nicely together in the same sandbox.