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
PostgreSQL has three shutdown modes: smart, fast, and immediate. For many years, the default has been "smart", but Bruce Momjian has just committed a patch to change the default to "fast" for PostgreSQL 9.5. In my opinion, this is a good thing; I have complained about the current, and agreed with others complaining about it, many times, at least as far back as December of 2010. Fortunately, we now...
EDB Labs
Amit Kapila and I have been working very hard to make parallel sequential scan ready to commit to PostgreSQL 9.5. It is not all there yet, but we are making very good progress. I'm very grateful to everyone in the PostgreSQL community who has helped us with review and testing, and I hope that more people will join the effort.
EDB Labs
A very popular standalone NoSQL database solution came under criticism about their security posture this week. It’s not the kind of publicity a database company – or any company for that matter – relishes. Although the vulnerability seems to have been less a problem with the core database than with insecure default settings, it’s worth remembering that, no matter what database you use, properly securing the database is an essential configuration step.
It's been over a year since I last blogged about parallelism, so I think I'm past due for an update, especially because some exciting things are happening.
Database performance and hardware selection are complicated topics, and a great deal has been written on that topic over the years by many very smart people, like Greg Smith, who wrote a whole book about PostgreSQL performance. In many cases, the answers to performance questions require deep understanding of software and hardware characteristics and careful study and planning.
Last week, Linus Torvalds merged a Linux kernel commit from Mel Gorman disabling vm.zone_reclaim_mode by default. I mentioned that this change might be in the works when I blogged about attending LSF/MM and again when I blogged about how the page cache may not behave quite the way we want even with vm.zone_reclaim_mode disabled. For those who haven't read previous discussion on this topic, either...
When your database gets corrupted, one of the most important things to do is figure out why that happened, so that you can try to ensure that it doesn't happen again. After all, there's little point in going to a lot of trouble to restore a corrupt database from backup, or in attempting to repair the damage, if it's just going to get corrupted again. However, there are times when root cause analysis must take a back seat to getting your database back on line.
Business Transformation
Last month, ZDNet published an interview with MongoDB CEO Max Schireson which took the position that the document databases, such as MongoDB, are better-suited to today's applications than traditional relational databases; the title of the article implies that the days of relational databases are numbered. But it is not, as Schireson would have us believe, that the relational database community is...
In addition to talking about PostgreSQL at LSF/MM and Collab, I also learned a few things about the Linux kernel that I had not known before, some of which could have implications for PostgreSQL performance. These are issues which I haven't heard discussed before in the PostgreSQL community, and they are somewhat subtle, so I thought it would be worth writing about them.
EDB Labs
Last week, I attended the Linux Storage, Filesystems, and Memory Management summit (LSF/MM) on Monday and Tuesday, and the Linux Collaboration Summit (aka Collab) from Wednesday through Friday.