 In the spirit of being an event that runs on time, we'll get started here with the next session. This is Joe Conway. He's been a committer on the Postgres project for almost 20 years. He's going to talk about both the Postgres community and some upcoming features in the next releases. So, Joe, take it away. Thank you. Can you guys hear me in the back all right? Good. So, like you said, my name is Joe Conway. I'm the VP of Engineering at Crunchy Data and a long-term community member, committer. I'm on the infrastructure team for the project, and I'm also on the board of directors for the U.S. Postgres Association. So, what I'm going to do is I'm going to cover a little bit of history about the project and then quite a bit about how the community works. And then, toward the end, I'm going to cover at a real high level stuff that hit in Postgres 11, kind of more like a bullet list of features that maybe will catch your attention and I'll zero in on a few of them. But if you want to see real details about those things, one of the other community members and a core team member, Magnus Hagander, is giving an in-depth talk about Postgres 11 certain select features in Postgres 11 tomorrow in the dev room. So you should go check that out, too. And I will touch on some things that have been committed toward Postgres 12 and some other things that are being still worked on and might or might not make it into 12. Now my laptop is freezing. It's happened to the last guy. Yeah, it's working. All right, so, maybe, yeah, I guess I'll just have to use the switch on the computer. So the Postgres project started at the University of California, Berkeley. This is just a couple of pictures from the campus. But even before that, there was a project at Berkeley called Ingress. How many people here have heard of Ingress? Actually, quite a fair amount. It's not very popular these days. But basically, in 74, there was a professor named Stonebreaker at University of Berkeley. And he started a project which was really kind of the first modern relational database. And they called it Ingress and it stood for Interactive Graphics Retrieval System, which interestingly doesn't sound much like a database. But I think it was because his grant was actually based on something else and he decided to build a database with it or something like that. And that went on to spawn some well-known commercial databases. This has, you know, its roots can be seen in Sybase and MSSQL, something called nonstop SQL and some other database technologies that are out there. And in 1980, Ingress actually became a commercial company and then changed names several times. And it's actually still around today as a company called Actian, and they open sourced Ingress back in 2006. So you can still use Ingress, you can get the source code for it, you can get support from Actian. And that's not going to work. Okay. So in 1986, the same professor Stonebreaker started the Postgres project and the idea was it was Post-Ingress. So that's literally where the name comes from, Postgres. And it was supposed to be the next generation. It was an object-relational database. At this point in time, there wasn't an actual SQL standard. So they invented a language called Quell that you would use to query this database. And that original source code actually spawned other commercial databases, including Illustra and Informix, which I think at this point are pretty much dead. Illustra, Spawn, Informix, Informix got bought by IBM, and I think it kind of died a quiet death a few years ago, although I still hear about people using Informix from time to time when they're converting to Postgres. In 1994 and 95, there were two students, two graduate students, I think at Berkeley named Andrew Yu and Jolly Chen, and they're the ones who basically took the SQL, which was now an emerging standard, and strapped it on to what was Postgres at the time. And at the same time, they also critically modified the license and made it more liberal because that set us up for 1996, which is when the Postgres project actually was formed. The community started with commits into CVS from the original code that came from Berkeley in 1996. So you can see, as an open source project, Postgres has been around for over 20 years now, and as a source code, the project has been around for over 30 years now. So it's been around a long time. It's really pretty much as long as all of the other commercial databases that are out there. Also, I make note that there is a wiki page which shows all the different derived products from Postgres. So one of the things, because the license is so liberal, it's basically described as either a BSD form or a MIT form license, which the way the community generally sums it up is you can do anything you want with the source code, just don't sue us. So because of that, it's been forked and made into many different things over the years. And you can see based on this list, there's quite a lot that has been spawned by Postgres as a project. Many of these commercial entities that have made good money from it. So just for fun, I have a couple of pictures here. This is Michael Stonebreaker, the originator, Jolly Chen and Andrew Yu, the two guys who turned Postgres into SQL database. And this was the original core team. A few of these people are still around. Tom Lane and Bruce Momgen are still members of the core team. These other folks have come and gone for the most part, worked on various parts of the system. Vadim did the major work on MVCC, which is the transaction control that Postgres uses. Thomas Lockhart did a lot of the work on the early work on daytime data types and so on. And our first conference, basically, as a community was in 2006 for the 10-year anniversary of the open sourcing of the project. So this is a picture of all the people out in front of University in Toronto, I think it was. I'm in there somewhere. There's a bunch of people that are walking around the halls here. There's a Postgres table up kind of behind us over here. And a bunch of the people that were in this picture 13 years ago are still active members of the community and walking around here today. So this diagram I got actually last year at the Postgres dev room. There was a talk by, and I know I'm going to butcher her name, Latitia Avaro. And she put this slide up because she was talking about the Postgres community and it struck me as like a perfect slide for describing how the Postgres community works. And I had been thinking about the structure of the community for many years, but I had never actually put it onto a slide. And when I saw this, it was like, I've got to use that. So she gave me permission to use it, and I've used it a few times now. But basically, in order to understand the community, this kind of, this ring form over here is important. There's a core team that's five people. They provide the governance for the project. But closely associated with them and also included in much of the governance are the people who have commit access. There's 28 total people with commit access, including a few of the people who are on the core team. So the entire project is basically managed by that core group of people. But for every release, there are a lot of people that are not part of that core group that submit patches, review patches, they do translations, they do testing, they run what we call build farm animals, which is how testing gets done in an automated way across different platforms. So all of these people are very important to the community as well. These are the people that are doing reviews. People are developing patches. The people are doing translations. Postgres is translated and the actual error message and so on are translated into quite a few languages. So that's all due to that larger group. And that group keeps growing, release after release. I think someone did a count on the release notes for a major release. We try and name everyone who did something that was kind of directly touched, something that got committed. And maybe someone can correct me if I'm wrong, but I believe the list for Postgres 11 was something just over 300 people. So there's quite a few people that get involved in the production of Postgres as a database. Now also you notice that we have over here user groups and associations and advocacy. And as I mentioned, I'm on the board of directors for PGUS. There's a PG Europe organization. There's an organization in China, I think in India. Probably, I'm sure there's one in Russia as well. There's a bunch of them basically spread out. And mainly what they're there for is to advocate the use of Postgres to teach people how to use Postgres. And so those groups run most of the Postgres specific conferences where you can go learn in depth from experts. And that same group, Postgres Europe, is running a Rana PG Day here in Brussels yesterday at the Marriott, and they're running the dev room tomorrow. So tomorrow the dev room will have, I don't know exactly how many, six or so talks that will be dedicated to Postgres. And then further, you've got the users, everyone who's using Postgres, maybe participating in the mailing list, maybe not. Those folks are all part of the community too. We've got a very active and robust community. We get lots of feedback from the users that gets incorporated into fixing things that are broken or new features that come out. And so the project is very much driven by its community. Sometimes it works, sometimes it doesn't. So this picture is kind of to show you what the Postgres development cycle, a typical development cycle looks like. So this is probably, I don't know if this is readable in the back of the room here. But basically at some point here in the kind of August time frame last year, excuse me, in 2017, we branched a stable branch for Postgres 10. When that happens, basically we open up development on whatever's going to be next. So in this case it would have been Postgres 11. So all the new development starts. As part of the development process, we have a number of these commit fests. CF here, CF 1, 2, 3, and 4 commit fests. I'm going to go into that in more detail, but basically commit fests are where the other people who have submitted stuff patches, where we focus as a community on reviewing those packages, getting them cleaned up to the point where they can be applied and getting them committed. So we focus on what everyone else has provided during those time frames as opposed to what the committers themselves maybe want to work on. And more and more in recent years, even the committers have tried to put their patches into this commit fest process, which I'll describe later. There's also, we do that one month at a time and we skip a month in between. So this is typically here for the Postgres 11, this was September, November, January, and March. This year we actually added a fifth one. We branched a little early and for Postgres 12 we actually have five commit fests. We started a bit early. But this is pretty typical over the years. You also notice I have this developer meeting at Fosdown, which is something we did this Thursday before we had the PG Day. And then at the end of this fourth commit fest, that's when we call feature freeze for that release. So the end of March or basically that usually spills over slightly into April. But about the end of the first week in April we called last year, we called feature freeze on Postgres 11. And then shortly after that we declared a beta. Do beta testing in here. There was a very short release candidate cycle and then we released 11 here toward the end of October last year. So our goal is normally to get out a release once a year and we are generally shooting for... Testing? Yeah. So we try and get a new major release out once a year. Still not? Yeah. Testing? Yeah. Just a little. Okay. In the September timeframe, the project is very conservative. So if it's not ready to go, we're not going to ship it. And again, I'll talk a little bit more about the process of how we get that done. But there have been years where the major release slipped into, as it did last year into October or even kind of later. And we've been making consolidated effort recently to kind of pull it back to where it would happen closer to September. So just a note on the versioning. How many people here are familiar with how Postgres does the versioning and the change recently? Not too many. So this could be something that would be confusing. Up until version 9.6, Postgres used a three segment release version. So this 9.6.8, 9.6 in this case is actually the major version portion. And the 0.8 indicates a bug fix release. So that's important to understand because one of the other things about the Postgres community is new features only go in the major releases. And the bug fix releases are truly only bug fix releases. And so therefore you really should, as soon as you can, when a bug fix release comes out, you should try and go apply it to your production systems because it fixes known bugs and it shouldn't create any regressions. Over the 20 years I've been involved with the project, I can remember a very small, less than one handful of times where there was some kind of a regression that was caused by a minor release. There are definitely a lot of things that get fixed in every minor release. So highly recommend that you upgrade those minor releases. The major releases take more planning and more effort so you can space them out a bit, but not the minor releases. How's that? That's good. So anyway, starting with Postgres 10, we switched basically to a two segment. So now 10 is a major release, 11 is a major release, 12 will be a major release. And when you see 10.3, that's actually a bug fix release. Probably the other thing that's worth noting here is that the minor releases, we usually target those about once a quarter. So if there is some kind of an emergency, some kind of a data loss bug that's discovered or a security issue, we do sometimes do interim minor releases. But they tend to come out, if they're coming out as scheduled, they come out once a quarter. And there is a dates listed on the Postgres website for that. So now I want to talk a little bit about the commit fests. We have this app that was put together by one of the core team member, Magnus, wrote this and maintains it. And basically this is a place where if you've got a patch that you want to submit to the Postgres project, you would go register it on the open commit fest. So I don't know if you can see this. So you can see here the 2019.03 commit fest, which is the March commit fest, is currently open. That means if you had a patch you wanted to submit to Postgres, you would go register it in there. Let's see if my internet connection works. And you can see when you go in there basically each patch gets a line item. It has a status. I'm going to talk about some of these things. And this app is kind of designed to track the mailing list discussion that will happen on the hackers mailing list with respect to that particular patch, as well as keeping track of the last version of the patch and who's going to review it and who's planning to commit it. So one entry in that commit fest can be either one patch or it can be a related set of patches that build on top of each other. And they implement some goal. It might be a bug fix. It might be some refactoring. It might be documentation improvements or it might be new features. And there are going to be one or more authors and one or more reviewers that are listed. And as I just said, it can be really a whole variety of things that are included in those. The goal of the commit fest is that patches don't get lost. Before we started doing the commit fest, we were getting an increasing volume of patches being submitted by people outside of that core group of core team members and committers and things would start getting lost through the cracks. And so the goal of this is to make sure that everyone who does want to participate in the community gets a fair chance at actually having their patch reviewed. The other thing is it makes it easier for us to find things that need our attention. And the goal here is also to encourage, if you're going to submit five patches that you want to get into Postgres 12, let's say, the hope is that you'll go review five other people's patches because that's the only way this process is going to scale. So in a nutshell, that's what we're trying to do with that. The entry states, as you can see here, needs review. Basically, that's a patch that needs someone to look at it, not necessarily a committer. And again, in fact, the idea here is that we can have people who are not committers doing the initial triage on these things, helping them get improved to the point where they're ready for a committer. And then once they're marked ready for a committer, because that's a scarce resource, a committer will go spend time on that. If the reviewer says something needs to be fixed or changed, they might set it back to waiting for author because now they're basically asking the author to make some change. Once it gets committed, obviously it gets marked as committed. We do have patches that get rejected. For a variety of reasons, sometime the author submits a patch and then kind of disappears, and we have feedback and they don't address it. Sometimes we end up marking them as returned with feedback because no one else wants to pick up a patch and finish it. And we can also have them get moved to the next commit fest. The basic process is that the day before the commit fest starts is the deadline for getting a patch in for that open commit fest. And that's defined as anywhere on earth. So at the end of February, anywhere on earth, you can still submit a patch and get it into the commit fest. And when the commit fest starts, all patches should either be in a needs review or ready for a committer state. We assign someone from the community to be a commit fest manager, that person is basically the one who's going to bug everybody and try and keep things moving, keep the statuses updated and whatnot. The reviewers will review, provide feedback, the authors will make adjustments, and then when it's finally ready, it'll get committed. If we're waiting on an author for too long, we will mark it as returned with feedback. And at the end of a commit fest in particular, if the patch still needs review, we'll automatically move it to the next commit fest. But if it's waiting on author at the end of the commit fest, it'll automatically get marked return with feedback. And so the author now needs to take some action to address whatever the feedback was in order to get it into another commit fest if they care to do that. The other thing is the last commit fest, so that commit fest in March that I showed you, that's the last one of a development cycle for a major version just before feature freeze. We do have an extra rule that basically something that's large and invasive shouldn't show up for the first time in that commit fest. We're also much more aggressive at taking large patches that look like they aren't going to make it in before the feature freeze and marking them return with feedback or whatever and moving them to another commit fest for the next major release. Okay, so now I've got some metrics here for you. This is the 9, 6, 10, and 11 cycles. You can see here 9, 6, we also had 5 commit fest. In 12, we're going to have 5 commit fest. You can see the level of activity here has been going up pretty steadily. The stark part of the bar is the committed. So you can see we're getting more stuff committed. Move to the next commit fest, stuff that just didn't get finished. And that's also increasing in size. The rejected is pretty consistent throughout. It's small, but it's there. And return with feedback has actually increased a bit because we've had more stuff submitted. Some statistics out of the repository. This is going all the way back to Postgres 7.2, which was, I think, back in around 2001. So the number of files changed from major release to major release is increasing but not by a huge amount. Insertions and deletions of lines of code is actually, with the exception of a few spikes, has been pretty consistent. And the diff size, again, Postgres 10 seemed to have an abnormally large diff size for some reason, maybe because all the partitioning code that went in. And that's been kind of slowly increasing from release to release. Okay, so now I'm going to cover some of the things that got committed in 11. I just wanted to start first with, again, some numbers. It's kind of funny. Someone was showing me last night, I guess someone did a blog about the talks at Fozdom and there was a satirical blog and basically they were roasting each of the talks. And so what they said about mine was that I was going to stand up here and read you the commit logs for an hour. But the funny thing is, I actually went through the commit logs for Postgres 10 and Postgres 11 putting this talk together. I'm not obviously going to try and read them to you because they're like 15,000 lines each. But I thought it's good to look at kind of the variety and the absolute numbers of how many things get done in each release. So you can see here, bug fixes, 84. A bunch of client work. Does anyone here know what ECPG is? Steven, you don't count. I didn't even know you were back there. You can see even down to code comments, documentation changes, lots of performance related stuff and I'll get to this in a little bit, in a little bit more depth. You can see a lot of things having to do with parallel query and partitioning. And trying to categorize these is kind of hard because there's a lot of crossover. Some of the things that are kind of partitioning related are also kind of performance related as well and vice versa. Procedural languages, refactoring, 38. So these are just patches that did nothing but move code around to make it easier to understand and maintain. Postgres code is by most accounts some of the cleaner source code out there for open source projects. I don't know if everyone will agree with that. And certainly in the community we sometimes complain about our own source code. I think in general it's pretty good. A couple of security fixes, a bunch of things related to the server features. New SQL commands, sysadmin. All right, so here's a list now of things that did get committed in 11. And again, if you want in-depth information about these, go see Magnus' talk tomorrow. I think, do I see him back there too? Go see Magnus' talk in the dev room. He'll go into more details about a subset of these, I'm sure, the more important ones. But some of the ones that are interesting, this is the list of things having to do with partitioning that got into Postgres 11. So you can see it's quite a bit. Partitioning kind of became a full, fully supported feature. I mean, we've had it for a number of years, but in 10 it became part of the grammar. But it was the first release with the partitioning, and so there were a lot of things left to be done. And you can see a lot of that got done in Postgres 11. Things like hash partitioning, partition-wise join, the ability to create indexes that will be replicated on all the partitions, lots of improvements for faster use of partition tables. So in general, if you have a need for partition tables with Postgres, you definitely want to be on 11, and probably 12 when it comes out. Again, parallelization, parallelization first hit Postgres in 9.6, but it has steadily improved with each major release. So some important things here to note, you can do now hash joins in parallel, B tree index builds in parallel. Queries with a pen plan nodes, I mean, that's kind of not easy to understand, but things like union queries that would apply to, it also applies to things like partition tables. Limit clause gets passed down to the workers, and now if you use limit clauses and you have a parallelized query, it can be a lot faster because of that. Lots more in the area of performance. More of this pushdown of limits. Automatic pre-worm. How many people here are aware of PG pre-worm? Yeah, again, you guys don't count. So that's an interesting extension to Postgres. You can use it to basically, when you first start up your server and your caches get warmed up by your actual queries, well, you can use this to basically save that warmed state and so if you need to restart your server, you can start it back up and get it back to a warmed state much more quickly. And that's been improved in Postgres 11. Let's see what else is notable here. Index only, bitmap scans, covering indexes. So covering indexes, this is where you build an index on some columns, but you can include other columns in there that you basically don't want to be part of the index but you want them to be in the index so that we can do an index only scan instead of having to look at the heat. So that's another significant performance boost for certain types of queries. Just in time compilation, I don't want to forget that one. So that's a big one. Postgres 11 is the first release with it. There's similar to what I was just saying with parallel query and with partitioning. The first release of JIT is going, it's great, but it's limited in scope so I would expect to see over the next several major releases continuing refinements and improvements to the way that works. Logical replication now is truncation support, constantly doing improvements to test coverage, some authentication improvements. There's a lot of stuff in this miscellaneous list. You can now build if you're wanting to build on Windows. I don't personally recommend it, but if you want to do it, do it with Visual Studio 2017 now. Fewer super user checks. This is an important one. Steven back there was involved in that. Basically, a lot of things that we used to require the super user to do are now grantable to normal users so that you can use the principle of least privilege. You can basically just grant privileges to do specific things to specific users instead of having to give them super user to do that. SQL procedures with transaction control. So this is actual stored procedures. For years, Postgres, people talk about Postgres functions like they were stored procedures, but they're really not the same thing. Stored procedures can run with their own transaction control. So now you can basically build procedures in Postgres that act more like maybe your scripts were doing before. And it also puts us on a par with other database systems that have similar things. See if there's anything else I wanted to note. You can allow an external command for getting a passphrase for SSL key files, so you can have your SSL key files in password protected, basically, but not have the server prompt you to type a password at startup. And again, some more Windows support for huge pages. PG Bench is the tool that comes with Postgres for doing kind of basic benchmarking. There's been lots of improvements made to that over time. It's like a Swiss Army knife. You can do all kinds of different things now. P-SQL is the command line client for Postgres. The Postgres users, the hardcore ones, typically like the command line versus some GUI tool. And consequently, this tool gets a lot of love. So it's a very good command line tool. It makes very good use of ReadLine for command line history and editing and all kinds of other stuff. So more improvements to that. But the big one to note here, I guess I don't quite get why this was so important, but to a lot of people, this was huge. You can now just type quit or exit and exit. Okay, so now I'm just going to touch a little bit on things that have either been committed since Postgres 11 branched, so things that would get into 12 or are currently being worked on. So in terms of things that have actually, and this is a little bit old, we just are finishing up another one of these commit-fests. This was done at the end of the commit-fest in November. Things were moving too fast. I didn't really want to complicate the slides by trying to get it right up to date. So it's missing like the last months were the commits. But in any case, the Git log from when we branched Postgres 11 to this point at the end of November was almost 15,000 lines. So a lot of stuff got committed. Now a lot of that is bug fixes that are also getting backpatched to the older stable branches. So when I go through it, I look for things that were just net new for Postgres 12. So again, a bunch of new performance-related things that have been included in, that will be included in Postgres 12. Some of these are pretty arcane, but allow multi-inserts during copying to a partition table, hand-code string to integer conversion for performance. I mean, these are the kinds of things that happen in Postgres all the time. I'm not even sure if I have it on the other slides, but there's a guy right now, a man, Andrew Gehrth, who's working on a whole new way to print out floating point values because of the speed improvements that'll provide. There's been a logging improvements, an application name to the connection authorized message. Improve auto-vacuum. How many people here are familiar with auto-vacuum? How many people like auto-vacuum? They should actually like it. Of course, there are some improvements coming that maybe will make that potentially obsolete. More improvements to P-SQL. Again, miscellaneous replication slots dropped in single-user mode. So again, the procedural language being able to create procedures in Postgres was new in Postgres 11. And again, similar to those other features, it will get better with each release. So in 12, you'll be able to use polymorphic argument types with procedures, which means you can create a procedure that basically will take different types of arguments, integers, floats, or text, and do the right thing at runtime as long as you design them to do the right thing. One to note here, if you do development in particular, we started to require C99 for Postgres, so we're now requiring a 20-year-old compiler. And in fact, we don't even really, in the source code, we don't support all aspects of C99, but that is required now for the compiler, which means if you're going to compile on Windows, you have to have MSVC 2013 or up. Extensions can now install their own headers. Oh, another important one. Recovery.conf has been integrated into Postgresql.conf. So if you're used to setting up high availability or replicas of any kind with Postgres, you're used to manipulating the file called Recovery.conf, that now actually goes away. There's a bunch of new functions. Some of these are related to the effort to allow non-super users to do more things, principle of least privilege. There's been settings added for control of SSLTLS protocol version. There's been a few things removed. I kind of doubt anyone's using these, but there was a time travel extension that is gone. These data types, abs time, rel time, interval are all gone now. They've been deprecated forever, so hopefully you're not using them. Postgres originally supported OIDs on every table, but that's been deprecated for years and it hasn't been the default for years, and that's now been pulled out. In terms of ongoing discussions, things that have not yet been committed, the biggest one is this pluggable storage. I was just talking to Andres, who's been working on that, and it sounds like there's a reasonable chance that pluggable storage itself will get committed for 12. Zheap is one of the first new types of storage that would make use of this pluggable storage layer, and talking to some people about that, it sounds like Zheap will probably not make it into 12, but it's an ongoing discussion. Zheap is the thing I was alluding to earlier, which will, I think, if I understand it correctly, eliminate the need for vacuum because of the way it works. It works more like Oracle with undo logs, which should give you shivers. But there's been an ongoing discussion for a while about a feature called Merge. It's an often asked for feature. We've got similar functionality in other features in Postgres already. This one actually got committed for 11 and then got pulled out because there were problems with it, and then I think it got committed again and pulled out again, something like that. Just looking at these guys back here. So it sounds to me like Merge is probably not going to make it into 12, but you never know, it could happen in March. There's other features having to do with the JSON standard. There's been work, I doubt this would get into 12, but there's been work going on now for a couple of years, sort of at a low level to go to 64-bit transaction IDs, which would have an impact on something called Rack Transaction Wrap-Around. There were talks yesterday at the PG Day and at the Marriott on database encryption. I don't know whether that is likely to get into 12, but I think actually the author of that yesterday said they hoped maybe it would get into 13 or 14. So that's, again, ongoing work, probably not going to make it into 12. Logical replication conflict handling, that would be one of the things that we need in order to make logical replication start to look more like a form of multi-master. Synchronous logical replication. Alternatives to open SSL. I know this is one that I'm interested in. I know Stephen back there is interested in. There's some discussions about, and I think maybe that actually is a chance to get in to 12. Global indexes. Postgres with partition tables, you can create an index that will automatically get created on the partitions, but that's not an actual global index that spans the partitions, and that's something else that people have asked for. There are pluses and minuses to it. There are definitely use cases where I think it makes sense. Autonomous transactions is another thing that gets asked for a lot. I don't know where we are on that, but I don't think that'll make it into 12. So again, we'll be building more on logical replication. We'll be doing more with foreign data wrappers, hopefully. Foreign data wrappers are basically a way to call, get data from an external data source. And the Postgres foreign data wrapper, which lets you connect to other Postgres servers, is actually pretty advanced in the way it works. It does a lot of push-down of things that allow the queries to be optimized in a sensible way. But one of the things that it cannot do right now is it cannot actually go scan a bunch of foreign data tables asynchronously, kind of in parallel. So that's something that I hope will come in the not too distant future. Another favorite of mine is Create Variable. Inlining CTEs is being worked on and discussed on the list right now. That has implications for... CTE is a common table expression, which is basically a with clause. And the way that works right now is it's an optimization barrier. It gets optimized all by itself. That has implications in that that cannot then participate in parallel query. So there are certain types of queries where you want that to actually kind of get rolled into the main body of the query so it can get optimized and parallelized. So that's going to be important for a subset of people. And so that's all I have and I think I have probably about five minutes left for questions. If anyone has a question? Question, anyone? Parallel DML. I use a lot of other PostgreSQL also for business intelligence analytics and stuff is that parallel DML is something that's interesting. Okay, there have been discussions about parallel DML. I don't know... Can you guys in the back help me out on that? No? Basically you have parallel query now and parallel DML, which... Yeah, for great inserts and updates and so on. Yeah, it's definitely been discussed. I don't think it's going to be in 12. Okay. Anyone else? I have a tangential question to everything you were talking about. Is there a good book or a resource that describes all the new stuff that people can read and understand these things if I correct me if I'm mistaken? But I think the last book for performance tuning was written for Postgres 9.0 or something like that. Yeah. Are there any plans to get us any updates? Thank you. I know the author of that book and he's made some noises about maybe doing an update to it. As far as features go, really your best bet is to look at the detailed release notes that come out with a new major release because typically I think we do a pretty good job of providing links into the documentation. So if you kind of read through those release notes, they're not that terribly long and you'll get a pretty good view of what the major features are and the two or three that you're really interested in just drill in to what it says in the docs. Get on the Postgres General mailing list. People, if you post a question to the mailing list, you'll have an answer probably within 10 minutes. So that's what I'd recommend. It's hard for books to keep up with this, especially when we're making new releases once a year. So that would be the best advice I'd have. Any more questions? Thank you.