The Elephants In The Room: Limitations of the PostgreSQL Core Technology

hi so I'm Robert Haas I am a PostgreSQL contributor and committer and I work at Enterprise DB where I am the chief architect for the database server and today I'm going to be talking with a lot of echo about the elephants in the room or limitations of the PostgreSQL core technology and before I get to that I want to first say that PostgreSQL is a great database so you know it's got a reputation for stability and for standards compliance it has a whole bunch of great features some of which no other major relational database system has such as transactional DDL you can begin a transaction create an index drop a table and then you can roll it back and undo whatever you just did that's pretty cool PostgreSQL also has a strong ecosystem of supporting products that do all kinds of interesting things one example is post GIS which brings geospatial capabilities for the database it's got a great community that's open source so please don't take anything that I say in this talk to me and that PostgreSQL is bad that's not my point my point is rather wow that's a lot of echo I think the problem is I have this mic on - okay so my point is okay can somebody stand up there and advance the slide when I when I need to do that John can you Thanks so so my point is rather that we've gotten to a certain level of success that we have today with PostgreSQL and these are the things that I think we need to do in order to get to the next level of success next slide please so you know if you are a longtime member of the PostgreSQL community you may be tempted to look at some of these issues that I'm going to talk about today and say ah you know yeah that's really an issue but it's not really that big of a problem well I think it is a big problem or a wouldn't be in the talk on the other hand especially if you're a newcomer to PostgreSQL you might be tempted to say oh my gosh who's Chris Kuehl has problems I totally shouldn't I totally shouldn't use that and that's not the read reaction either don't panic these are problems but they're things we can fix or and and end up with an even better system than we have today so Wow now there's two people up there this is getting very crowded so yeah so here's my list of elephants I'm not going to spend too much time on this slide because all of these things have their own slides so next slide so PostgreSQL currently uses buffered i/o which means that when you read when we read a page into shared buffers it first gets copied into the operating systems page cache and from there it gets copied into share buffers when we write a page we write it out from shared buffers to the operating system page cache and then the operating system eventually writes it back to disk PostgreSQL is pretty much the only major relational database that does this and it might be a bad idea we should at least consider whether it's a bad idea one of the problems is that it is very likely that the buff that the buffers which are present and shared buffers will also be present in the operating system cache and if you cache two copies of something that means that you're gonna have to cache zero copies of something else that you otherwise could one copy of and that's not so good another problem that I've become aware of recently is that newer SSDs offer a feature called atomic writes and this is pretty cool PostgreSQL has a system which actually is actually quite an expensive system that we use to protect against the possibility that the system may lose power right in the middle of writing in a kilobyte page so part of that page ends up on disk and the other part of the write doesn't happen because that's when you ran out of power okay but this atomic write functionality offers potentially a way out of that you do an 8k write and you say it's all or nothing either to get this whole thing to disk or just forget the whole thing and these SSDs have this and exist it's exposed via a Linux kernel API that you cannot use with buffered i/o you can only use it if you're using direct i/o sucks for us so given these things you might ask why in the world do we use buffered i/o and the reason that's traditionally given is that we think that the kernel is going to do a much better job of scheduling i/o then we're going to be able to do ourselves and we don't want to re-implement the smarts that are in the kernel so let's just take advantage of the kernel getting smarter and smarter rather than reimplemented ourselves but I don't think that's really what's going on here what I think is happening mostly is that buffered i/o is that buffered i/o allows us to paper over the times when we make bad buffer eviction decisions next limit okay so here's a graph that my colleague John Veeck made as a result of some PPG bench runs that he did the blue line on here shows the number of transactions per second that we got during each second of this test and as you can see it's very spiky some of the time it's up between 1,500 and 2,000 and other times it's down near zero which is obviously not what we'd like to see but then made a really interesting observation explaining why that's happening the shaded red area on this graph shows the number of dirty buffers at each point during the test and if you look what you can see is every time the number of dirty buffers goat starts to go down our performance tanks every every time when that red number is sloping down because the kernel is doing those delayed writes to disk that I was talking about our performance dies so I when you see things like this you really have to say so just how intelligent is that kernel i/o scheduler that we're supposedly benefiting from I'm not saying there aren't other ways to improve this but that doesn't look good all right it's all I got to say about direct i/o if you're not mad yet wait till you see the next section okay so the next thing I want to talk about is our on disk format this is another graph from yawn it shows the results of running a TPCC like benchmark on PostgreSQL 9.3 and also on another database product okay now you can see that at in the first 30-minute run this was a series of 30-minute runs the first 30-minute run we did pretty darn well but we couldn't sustain it as we did additional runs on the same data set our performance declined and the performance of the other data based product remains much steadier which kind of stinks right the reason for that is the size of our data we started out about a third larger and both databases grew over the duration of the test but by the end of eight runs we were 80% larger than the other product well being 34 percent larger isn't great being 80% larger is really pretty bad right this is not gonna happen on every workload it's not gonna happen in all situations but on this test in this workload that's what happened it's not good I don't know which kernel version that okay a court according to Andres who talked to you on it's two point six point 32 no you can't ask that okay so so so there's two basic problems here right our data is too big and it grows too fast and both of those things happen for a variety of reasons the data is too big because one one big reason is that our tuple headers are huge compared to most other products they're 23 bytes it doesn't sound like a lot but when you got millions there were billions of tuples it adds up we waste space on alignment padding I'm not sure how significant that is and there are data types specific issues where we just don't do a great job in some cases of cramming down values into the absolute minimum number of bytes possible that doesn't sound serious sometimes it's not serious but when you have enough data again those bytes start to add up to two very significant amounts of space and we grow too much improving vacuum as we've done over the years is good don't get me wrong it's very good it's made life much better for so many people but it only contains bloat it does not prevent it the other product on that slide there can update rows in place without having to put another copy of the row into the table and then later come back and get rid of it and that is of course a huge benefit on a test like this because a table that is update only where you just replace one version of the row with another version of the row that's the same size and another version of the row that's the same size and another version of the road that's the same size you zero out your growth on that kind of table there were other tables here where we're both products increase experienced an increase in database size but but there were some tables where the other product had no growth and we had growth yeah so the question was whether okay I totally missed something there okay so the question is does this other product require that the rows be picked sighs no it doesn't it has some method of coping with that it's complicated I'm not here to explain how said other product works so you know a related problem is that when you're able to update rows in place then you only need to insert new index entries for the for the indexes where the corresponding value has changed we've got hot updates which are great they touch no indexes but when the index but if even one index column is updated we then have to go insert index entries for all of the indexes not just the ones where the value changed but for all of them and so there's stuff we can squeeze out here right there's an opportunity for optimization okay so that's all I'm gonna say about the on disk format okay so now I want to talk about replication and I think the first question about replication is well why do people replicate data there's a bunch of reasons there's high availability you have two copies of your data so that if your main server goes down you can failover to another server that has a copy of all that data you might want to do a database version upgrade so you install a new version of the server replicate it hangover and then swing your traffic when you're ready multi master replication if you have geographically distributed stuff that's a use case and then there's read scaling and you know I think it's important to emphasize that all of these things are things that you can do today but the only one that I think we've really nailed is the high availability use case streaming replication works really well for that it's really reliable does a great job these other use cases there are lots of tools available but you may end up with a combination of tools you manned using different tools for different purposes the list of ways that you can do these things on this slide is not intended to be comprehensive so if I've left out somebody's favorite tool for doing one of these things I apologize for that but but you do tend to end up with a bunch of different tools to do these things and so basically up until 94 you only had two real ways of doing replication you could use streaming replication which was great for what it did right which was mostly high availability although there's definitely ways with additional tooling to use that for read scale out and then you had trigger based replication solutions which were a lot more flexible let you do a lot more different kinds of things but there are issues around the performance of those solutions the complexity of those solutions and frankly there are also issues with adoption I mean how many people in this I mean how many people in the PostgreSQL community have written a trigger based replication solution for PostgreSQL I know I've done it anybody else yeah so there's like at least 10 people in this room who have done that right and so what that leads to is a fragmentation of the developer community many of these solutions even really well-established ones that lots and lots people are using Wow only have one or two people working on them and that's not a great thing and the user communities are also split so in 94 we got a big step forward here which is we got logical decoding so you can have a process that reads the right ahead blog and turns that back into a stream of inserts and updates and deletes Andris did that work it's really cool yay Andris but we're not out of the woods yet because you can't use logical decoding unless you have a replication framework that knows how to use logical decoding and we need a lot more here we need to be able to answer all of those use cases that I had on the previous slide with simple reliable high performance well supported solutions that are that are in core we need that that's all I'm gonna say about replication by the way the patches for all of these things are due next week so you guys better get coding all right yeah okay so now I want to talk about horizontal scalability and I think one of the really important questions that comes up with horizontal scalability is do we really need that and it's not a dumb question I mean database sizes are growing rapidly but you can get really big servers these days I mean you can get a commodity server with a terabyte even two terabytes of memory in it and then you can put your whole data base in memory if you can put your whole database in memory you can probably make that data base pretty fast right and these aren't even enormously expensive boxes and a lot of people's databases are nowhere near that bag I get buy 10 gigabytes 100 gigabytes that's easy to fit in memory if you want to and you your controller isn't too tight-fisted you know you can solve that problem so while there are certainly people who have databases that are tens of terabytes hundreds of terabytes petabytes there's an awful lot of smaller databases where horizontal scalability maybe is not really as as big of an issue as maybe we sometimes think it is one case where it is a problem though is with right scaling it is much easier to put more memory into a machine and make that machine able to cash a larger database than it is to get that database that that same machine to be able to write lots and lots of data changes to disk really really fast that is still a hard problem to solve another reason why people say well you know maybe we don't really need horizontal scalability is that you know it's often better to push some of the logic about knowing where the data is back into the application instead of just throwing everything into one massive database that is going to internally do all kinds of magic to spread your data around across multiple machines and everything is going to work wonderfully it might be better to have some application level knowledge of where all of that data is located you can then partition the data in in intelligent ways I mean that the the reality is that network latency is much higher than memory latency and that's not going to change so putting related data together and being intentional about how you group your data together has a lot of value and if you do that you may very well find that there is never really a use case for a scale out architecture within the database on the other hand there are certainly existing applications that were not written that way and sometimes people need to take one of those applications and scale it up and maybe the biggest thing is rightly or wrongly people who love other systems think that auto sharding works and they don't like it that we haven't got it whether they're right or whether they're wrong that's a little more arguable but they think they're right and if we don't provide that solution they may decide that they're going to use something else so we've got a sort of a horizontal scalability solution that has been maturing very slowly over the last five years in PostgreSQL 9.1 we got foreign data wrappers so that you could access data on a remote machine using an SQL interface I think that was an enormous ly successful interface lots of people were used it and it's been improved in every release since that in small ways 9.2 got better planner support and statistics collection and a bunch of other little stuff 9.3 got the ability for foreign data wrappers to write data as well as read it which was very important change it also got Postgres FTW into the core distribution so that using only code that was in the core you could make Postgres talk to another Postgres that's obviously really important 9.4 got trigger support for foreign tables and 9.5 devel as if a few days ago allows foreign tables to participate in inherence heritance trees and you guys may know that inheritance is sort of the way that we handle partitioning of data in PostgreSQL so the ability to put foreign tables in to inheritance degrees should sound a lot like the way we do sharding in PostgreSQL which i think it will come to be but we need a lot more here there is a slide missing the there is a whole bunch more improvements that are needed to this architecture in order to really do scale out with it well and we are creeping toward those improvements but we are not getting there I think nearly as quickly as we really need to get there for example if you're selecting data from to foreign tables and you're joining them you would like the joint to be done on the remote node rather than on the local node and right now you won't get that probably even worse if you are say doing an aggregate over the data like a really simple case is select account star from foreign table what we're gonna do is ship all the rows back from the remote node to the local node and then count them locally and it would be a lot more efficient to do the counting on the remote node and then just bring the count back and give it to the user but we can't do that yet right and there are other things too to have a real charting solution you might for example want to have consistent visibility between a group of servers and Postgres XE has developed technology to make that happen but in core Postgres we don't have that technology so there's a whole bunch of different things that are needed that that need to be done in order to in order to really make this this technology production grade another not production grade but to make it better and more capable and able to address a broader variety of use cases another one is asynchronous scans right if you have foreign table if you have multiple references to foreign tables in the same query we could kick off all of those scans at once at the beginning of the query and then wait for the answers to start to come back but today we don't we kick them off one at a time and when first one is done you take the second one off one second ones done we kick the third ones off so it's sort of a poor man's version of parallelism but it's it's an important performance optimization and we don't have it today I'm gonna be interested to see whether the slide that I just talked through without having it shows up later in the deck or if it's just totally gone okay so another place where I think we need to improve is parallel query obviously a big part of the driver for this is that CPU and core thread CPU core and thread counts are still increasing fairly rapidly but single CPU performance is really not going anywhere I mean it's increasing a little bit but it's extremely slow and so as your data grows it becomes more and more urgent to be able to operate on that data with lots and lots of processes at the same time there's good news and bad news about parallel query the good news is that my colleague Amit capela and I have a basic implementation of parallel sequential scan that's pretty close to being done I don't know whether it will go into nine five I think if it doesn't it will go into nine six there there is still work to be done there but I think we are getting fairly near to the end we're certainly an awful despite Andres shaking his head over there we are an awful lot we are an awful lot closer to the end than we are to the beginning and and I feel pretty good about that unfortunately by itself parallel sequential scan is not going to get us where we want to be right we need other types of parallel scans for example somebody mentioned to me last night a parallel bitmap index cat if you imagine that you have a huge relation you can use a bitmap in text to figure out that 75% of that big relation you don't want to scan at all but the remaining blocks you'd like to scan in parallel so we're gonna need that we're gonna need parallel ab grits there are little joins parallel utility commands probably a bunch of other stuff that I don't have on here there's going to be a lot of work some in terms of implementing additional parallel operators but also quite a bit of work in terms of making the query planner smarter so that it can come up with possible parallel plan using the operators that that we have so you know in one sense I feel like I'm just about to complete what has really been a really long journey I've been working on this for like a year and a half and I might have another six months to go but on the other hand there is an awful lot more that needs to happen after that and my hope is that all of the infrastructure that I've been building for this project over time will will make building the the second installment of this a whole lot easier than building the first installment has been we still have - we still have to get to number one before we can move on to number two so yeah and the last major area that I want to mention is connection pooling so there's a lot of reasons why people use connection pooling and a lot of people who are using PostgreSQL today are using connection pooling connection pooler's are I think one of the most popular add-on pieces of software for PostgreSQL some people use BG pool I think a lot of people recommend PG bouncer in cases where you can get away with it because it's simpler which of course has upsides and downsides but if you can manage with simple then that's better but I think we need to really give some serious consideration to why do we need connection pooling and why do we tell all of our users that they need to go and install a connection pool er to solve problem X or problem Y or problem Z and I think in order to answer that question we need to sort of list what the use cases are and I listed the five that I kind of know of on the slide here load-balancing right you've got a bunch of read replicas and you're using your connection pool or to direct some connections to one server and other connections to another server high availability your connection pool or is going to reroute the connection from one server to another server in the case that you have a failover event admission control you don't want the database server to get slammed by a huge number of processes all trying to do very complicated things all at the same time and totally swamp the machine so you use the connection Pooler to throttle the rate that queries are hitting the database to avoid the overhead of back-end startup and shutdown which is relatively expensive in postgresql and and even for replication where you actually have the connection pool or run the SQL statements that it thinks they're gonna write data on multiple machines so that if the stars align and everything works absolutely perfectly you will have two copies of your data and all of this is fine right there's a lot of useful solutions that can build that can be built this way but there are some disadvantages having an external connection pool or in the loop increases administrative complexity it adds an additional point of failure I can't conveniently count the number of times that people said well I don't have to worry about my database going down because my connection pool or will reroute the connections to another machine and then I said what if the connection pool er goes down oh I didn't think about that and and of course connection pool is also add latency because now every protocol message between the database and the client has this additional hop that it's got to jump through in both directions and you know I think to some degree were relying on the connection pooling to solve problems that we would really be better off if we could solve those problems in the core database server for example admission control I think is a particularly clear example of this why should it be the users problem to make sure that the database server doesn't get more connections at a time that it can handle gracefully should it not rather be the problem of the database server to say wait a minute you sent me a query but I'm overloaded right now so you've gotta wait it's exactly the same thing doing that and the database server as it is doing that in the connection pool are except that you need one for your component to make it work and you don't have this additional complexity point of failure latency so so PostgreSQL is already a tremendously successful system it's being used by a lot of people to solve a lot of really complicated problems it's being used by a huge number of big companies I know that because there are customers and and what we should do is we should try to make that system even better and what I've tried to do in this talk is sort of outline some of the areas where I think the big work needs to be done obviously there's a lot of small things about PostgreSQL all over the codebase here and there you can find well we could tweak this thing and make it a little better we could tweak that thing and make it a little better but these to me are sort of the big things the really large projects probably multi-year projects to really start making headway on these and and get to someplace that's really exciting I think in areas of logical replication and horizontal scalability and parallel query we've made a start the logical replication work as I said before is really due to Andres and of course assignment and everyone at second quadrant who who made that possible and all the people who helped fund it the horizontals and and I reviewed it yes I did review it and the horizontal scalability stuff has been really led by some of the Japanese guys and they just need more time we need more people to spend more time on those solutions to make them better and of course parallel query is largely my work with help from a bunch of other people at enterprise TV so we've made a start on all of those areas but we need to do a lot more in order to ensure our total world domination in some of the other areas that I mentioned Direct IO and changes to the storage format and building in connection pooling technology we really haven't tackled those issues we think of those as things like oh yeah you know it would be really great to do something about that but it would be so much work I'm not going to do that project and then we find some other area of the code to improve and so I think these are things that we really need to think about doing in order to in order to make the product better my final note here is please help like you not somebody else you helped there's a tremendous amount that goes into building these solutions you know I and my colleagues on the PostgreSQL mailing lists who are commit or all in that which is to decide when the code is at a level where it is ready to go in and become part of a product that's going to be unleashed on all of you but that is far from being the only important role there is review by lots of people that is needed to get those patches to the level of quality where we feel comfortable giving them to all all of you there is the writing of those patches someone's got to write the code there is the funding of all of that activity those patches do not get written by volunteers they get people who are paid by PostgreSQL companies there are certainly some patches that get written by volunteers but to make progress on these big problems we need more than that we need people whose job it is to write those patches and that requires money so all of the people here who work at PostgreSQL companies will be familiar with where the money to fund this comes from and that's that's from customers right so we need help from from people financially writing the code reviewing the code committing the code and then and this is also a very important part discussing what the solutions should look like and testing them once they are available to make sure that they actually meet the needs that you have so even if you're not a coder and even if you don't have any money there are still a lot of things that you can do to help make PostgreSQL even better because if you just leave it up to people getting around to other people getting around to doing something about these problems it'll probably happen but it might take a really long time so please contribute to that effort in any way that you can somehow I'm ahead on time which may be attributable to the fact that I spent the last week being frantically worried about being behind on time so I'm done thank you very much and if you have any questions I've actually got time for those so thanks Yeah right so the question is how much of the process is deciding on what the solution should be and how much of it is actually coding it I think it is both what I would say about that is that if you are the kind of guy who writes code and many people in this room are whether you are or not you may have a tendency to think that writing the code is the important part of the problem and that the deciding what it should do is the kind of BS thing that the community makes you do before you get to the important part which is writing the code I don't think the evidence bears that out right I actually think that that process of figuring out what the solution should be which is sometimes called design it is actually an incredibly important part of the process and I think that you know andris and I have reviewed each other's patches a lot and both of us go crazy with the things that the other person tells us we need to change in our patches but the patches get better right not everything that the other person suggests is an improvement but that's going to be true in any relationship that you have with another person in any situation right so I you know yeah the the design and the discussion of the design and the discussion of how the features should work and all that kind of stuff yeah that is a really important part of the problem and all of the things that I talked about here are very complex in terms of figuring out what are the right next steps but I don't think that as developers we should step back from that and say well jeez there's no hope and working on this project because I'm gonna have to figure out a design you should figure out a design and even if the design is the only part of it that you can help with that's okay that's great that's a huge contribution to help us understand what the design should be I think that comes out in the logical replication discussions where one of the things that's come up is well we're going to need control mechanisms for this to control what gets replicated and how it gets replicated and all of that kind of stuff and do we really know what those should mechanism should look like because if we don't know the use cases we might end up designing something putting something into the core product that everybody has to live with for 10 years that really isn't that good and we definitely don't want that to happen so yeah yeah yeah I think I think resource management as a general concept is a pretty important concept because we've got lots of evidence that when you over consume a certain resource the performance of the system goes downhill a lot in enterprise TVs Fork of PostgreSQL we actually built a resource limiting mechanism into our version nine point four and I think it is very likely that the community will eventually do things in that area as well so yeah I think resource limitation is part of it in in many ways the the transaction the the the the limiting of the number of active transactions could be a proxy for limiting a lot of other kinds of resource utilization and I don't actually know what's best here which gets back to that design question right exactly what is the best thing and how do you limit and how do you limit it limiting connections is one thing we've done a couple of other things that you can limit in in in advanced server 94 but some experimentation and testing will be needed in order to figure out which of those things are actually most valuable to people in which use cases it is although right that's only so accurate like it turns out that your plan costing can be way off and you can still get the right plans almost all the time so adding more dependencies on the plan cost is is a little iffy but yeah so Greg's question is whether I have anything to say about a particular topic but more specifically his question about is about trade-offs and what do you do when a particular change is going to make things better for some people and worse for other people it's a good question I mean I think you have to consider it in specific I'm not aware of a reason why using direct IO would be better for some people than other people or why it would regress anyone it probably would help people on large databases more because there's an awful lot of Postgres databases in the world where let's face it there's not that much happening right people spin up a database because they need a database but it may it may not actually process very many transactions I mean we have a we have an actual that I was working with on a support ticket and their transaction volume was I think one commit per week but that commit but that commit was really important right okay and you laugh but no seriously that commit was really important I can't tell you what it was but trust me it was important okay and we're having a little raffle here for a training and then I'll take that question somebody wins a free training it looks like it's Ryan Milwaukee okay all right you win a free training whoo question oh it's a great idea it would just be better if you didn't have to right so there are definitely problems with the with the connection pooling maybe making bad prioritization decisions about which queries to run what right away and which ones to put off nevertheless there are people getting enormous performance benefits out of using using connection pooling I mean really huge benefits so you know yes you could possibly make some of those things smarter if you put them in the core database and that's why I think we should consider doing that but people are also solving these problems in the connection pool are very effectively my colleague Kevin Grinner who's not here today will be happy to talk your ear off about what he did at the Wisconsin courts which basically involved limiting a huge volume of transactions down to something like 30 database connections and seeing response times just go through the roof and to do that he had multiple prioritization levels and multiple pools so that certain things didn't interfere with other things so it's tricky but it and it probably remained tricky even if some cases will probably remain tricky even if we have something in core but the benefits really are there if anybody in this room has a server with 500 database connections as a typical set up you should probably put a connection pool err in there and it will probably be faster if you if you tune it right and force that down to be shared among a smaller number of connections Peter so Peters question is about the importance of improving our caching algorithm I think if we want to give direct IO a try it's gonna be absolutely necessary because if you make a bad page eviction decision when you are using buffered i/o it's not great but it's not that bad either because you write the page over to the OS and then you're like oh crap I need that page again and you weed it back in from the OS cache and so you copied an extra 8k of data out you copied an extra 8k of data and yet it's a couple of system calls it's not wonderful but it's not terrible if you make a bad decision about writing a page out to disk and you write it out to the physically right of that to the disk and forget it completely from all of your caches so that you avoid cache duplication and then you discover that you need that page it is a lot more expensive to go get that page back so to have any hope of using direct i/o we would really have to make sure that our decisions about which things to cache in which things not to catch we're absolutely top-notch otherwise we'll get creamed yeah so the Linux kernel developers I think to describe why Oh atomic used Oh director I think they were using words like nightmare now I'm not a Linux kernel developer so I can stand here and say those guys are all weenies and you know they should really just figure out a way to do that and maybe they will it would be nice if they did but it doesn't seem like they have any plans to do that right now I do understand kind of why it's complicated right which is that if you do a direct write all you've got to do is go and write it and then when the write is done you can forget that that was supposed to be an atomic write if it's a buffered write and has to go in the operating system buffer cache you have to remember whenever it eventually gets written out this range of bytes has to all be written out atomically and by then more atomic writes may have come along even an overlapping bite ranges which wouldn't be an issue for us we would not have what we're lapping byte ranges but you know in general if they're gonna support that in the kernel they have to cater to those possibilities so it's probably a tricky problem to solve that with buffered i/o might not be totally impossible but what tricky definitely tricky Jeff absolutely yes right so Jeff is absolutely right and you know what one way of saying that is complain early and complain often you know because because I mean I don't run a production database I develop database code right and I have run production databases but I don't do it right now what I haven't run your production database so knowing for me and for I think for every PostgreSQL developer having feedback from people at conferences and on mailing lists and and at every other opportunity it presents itself to know what would be most helpful to you I mean you you've seen the things I talked about today come up to me or any other or the any of the other hackers in the room after this and say which things you think are most important for you which things are at least important for you the inputs always really helpful I think that we are out of time so thank you everybody for coming and I'll be around if you want to grab me afterwards you you

Channel: Postgres Conference

Views: 18,715

Rating: 4.8451614 out of 5

Keywords: PostgreSQL, PGConf.US

Id: zsF1vfHBMBI

Length: 51min 17sec (3077 seconds)

Published: Thu Jun 11 2015