CLAIRE: 00:00:00
Welcome to Talking Postgres, where we discuss the human side of Postgres, databases, and open source. For regular listeners, I want to point out that the podcast has been renamed. It used to be called Path To Citus Con, and as of early July 2024, our new name is Talking Postgres. Thank you to the team at Microsoft for sponsoring this community conversation. I'm Claire Giordano, and today's topic is how I got started as a developer and in Postgres. And our guest is David Rowley. David is a Postgres committer and major contributor to the project. He works on the Postgres team at Microsoft. He spends the majority of his time in his job working on Postgres open source with a specialization in performance, specifically speeding things up in the query planner and the executor. I would say that David is also an expert in Postgres partitioning, and he's based in New Zealand. He's also an avid outdoorsman, so he does a lot of backpacking and camping and hiking and whitewater, I think it's whitewater rafting, but we'll find out, I suppose. Welcome, David.
DAVID: 00:01:11
Thank you. Thank you for having me on the show.
CLAIRE: 00:01:14
I'm very excited that you said yes to the invitation All right, so we're going to dive today back in time to learn more about how you got started as a developer and in Postgres. But even before you got started as a developer, I'm wondering if there were moments in your growing up years where you knew that you were going to do something having to do with math or science or computer science. Was there somebody who influenced you or something that happened that pushed you in this direction?
DAVID: 00:01:52
I don't think it was really a single point in time that that happened. I think it was probably a lot of different things that just sort of pushed me in that direction. I remember probably the first introduction to computers was, well, my first computer was an Acorn Electron. This was a company that, Acorn, they really only existed in the UK. I think they started out doing computers for schools mostly, and then they sort of branched out into home computers. Anyway, my dad came home with one of these at some point and it came with this book. It was like a ring-bound book. It's a user guide, Acorn Electron user guide, I think it was called. It had a series of example programs in that. I just got started. I've been trying to find out what age I was when this all happened. I don't know. I think it was like between six and eight. I started typing in programs to see what they did. I didn't really understand a great deal about what I was doing, I think. I'd say that was my first introduction to programming.
CLAIRE: 00:03:25
It's interesting. It almost suggests that, I suppose a lot of children are curious, but the words you just used, that you started typing in programs to see what they did, you must have been curious.
DAVID: 00:03:40
Yeah, I definitely was.
CLAIRE: 00:03:46
Maybe that's that seminal moment. Are there other moments that you remember where that interest in math or computers or even science was fueled?
DAVID: 00:04:02
I think I always wanted to build things. One of the things I did when I was a kid was I had Lego. It was just Technics Lego, so it was kind of engineering focused. You had electric motors and rivets and differentials for cars and things like that. I spent quite a bit of time in my youth working on that. I think I just like to build things. I think, as you mentioned earlier about my interest in performance work for Postgres. I don't know, I used to, in my teenage years and twenties, I used to ride motorbikes a little bit. Performance of motorbikes was always an interesting topic. I think I get a similar little buzz out of speeding something up in Postgres, as I did maybe like tuning my motorbike or something when I was in my twenties. It's quite exciting to make something just go a bit faster.
CLAIRE: 00:05:17
I like it. We're definitely going to talk about that focus on performance. Because that is how you spend a lot of your time that you spend in the code on Postgres. Let's pivot to how you got started as a developer. When did that happen? Was that during the motorbike phase or after the motorbike phase? When did you do it as a hobby and when did you do it as your first job?
DAVID: 00:05:49
My first job, it's a little bit of a strange story. I'd been traveling after I finished high school. I went through a slightly less trodden path. I ended up going traveling for a while, for a year in Australia. When I came back, it was when I realized that I had to go and study and do something with my life. I didn't really have plans until that point. I'd spent so long thinking about travel. I got a job in a factory where they process cheese. I was working in the warehouse driving a forklift. I'd done some courses since I'd come back from traveling. It was related to Visual Basic.NET so I had a bit of understanding about building user interfaces. It was quite a new factory. It had only been built in the last year, year and a half when I started. Everything was quite modern in terms of the factory machines, but their systems for recording information were non-existent. There were pieces of paper. I was asked to build them a system to make this better. I migrated out of driving forklifts and into this role of writing the software. That was my first programming job.
CLAIRE: 00:07:45
How did they know to ask you rather than somebody else?
DAVID: 00:07:51
A couple of things happened when I was working in the store. I developed a couple of things just to make life a little bit easier. I think that sort of triggered them to maybe look at my resume and CV that I'd sent them, which had included the courses that I'd done for that Visual Basic.NET user interface stuff. I think they probably took a risk doing that. They asked me if I would do it and I took the weekend to think about it. I thought, "I've got to do this. I've got to give this a try." I was 23 at the time, I think.
CLAIRE: 00:08:41
It sounds like you're not only writing and developing software, you're architecting it, if you were starting from a blank sheet of paper, which it sounds like you were.
DAVID: 00:08:55
I absolutely was. The spec they gave me to work on to develop this was "store the data in a SQL database." That was it. I had to fill in a lot of the blanks. Nobody was an expert there. There was a finance guy. This is a cheese factory in a small town in Scotland where I grew up. I had to research and fill in a lot of the blanks. I ended up using MySQL for storing data originally. It was a few years after that that I migrated that application to Postgres for a number of reasons. That was my introduction to Postgres.
CLAIRE: 00:09:47
You're saying that you stayed in this factory developing software and evolving that software for several years then? Or did you leave and then were brought back to do this migration from MySQL to Postgres a few years later?
DAVID: 00:10:04
That software, I was developing it almost full-time for seven years. It ended up being quite a big piece of software. It started out in a small area doing one thing. They saw it was working and for what it was doing it was making things better. It crept into more and more areas of the company. I did have other responsibilities. For the first four years it was a full-time job. Then for maybe the last three years of that job it was part-time.
CLAIRE: 00:10:49
I had no idea that you got your start working as a developer and in databases in a cheese factory in Scotland. I love the visual.
DAVID: 00:11:01
That's actually working in Postgres there was when I found the community and when I submitted my first patch to Postgres.
CLAIRE: 00:11:09
You were still working for this company?
DAVID: 00:11:12
Yeah, it would have been 2008. I must have looked. I must have needed an answer for something. I'm assuming I haven't checked this but I must have either read something on the mailing list or sent an email to the mailing list. That's when I discovered it so I started following it loosely, not closely. I think I must have looked at the to-do list at some point on the wiki page. I picked something off there and thought I'd see if I can make that happen. That was my first contribution to Postgres. It was accepted.
CLAIRE: 00:11:54
I wonder if somebody who's here on the live chat could dig up that first email that you sent to the mailing list. I think it would be fun for you to glance at and remember the specifics of it. You're working in a cheese factory. This software that was originally created to make things easier, to move things off of paper and into a database, evolved more and more features it sounds like, crept into other areas. You're starting to interact with the Postgres community. Then what happened?
DAVID: 00:12:37
I left that job and went traveling again. I mentioned earlier about going to travel in Australia. I was 20 at the time and that was quite an eye-opening thing for me as a 20 year old to go across the world by myself and travel around. It was by motorbike. After that I went home and did that job for seven years. A friend announced that he wanted to go traveling and I also wanted to go. I left that job and I traveled for two and a half years. Part of that time was in Australia and then it ended up in New Zealand. I liked it. I managed to get a job and a visa to stay here. That's where I've been since.
CLAIRE: 00:13:44
For that two and a half years, was that predominantly in Australia and New Zealand? Or did you go to a ton of other countries as well?
DAVID: 00:13:53
I spent almost a year in Australia. Then I went back home briefly for a few weeks and traveled around Europe. I went to Norway and Iceland. This was on a motorbike as well. I ended up going to New Zealand after that. So basically Europe, New Zealand and Australia.
CLAIRE: 00:14:18
When you first went to New Zealand, also on a motorbike? Did you go to both islands?
DAVID: 00:14:28
I wasn't on a motorbike this time. My girlfriend was with me and we bought a car and traveled around. At the end of that, her visa was running out slightly before mine. We talked about going home. She's from Scotland as well. None of us wanted to. That was when I looked for my first programming job that was with a company that develops software rather than a company that develops cheese.
CLAIRE: 00:15:10
Are you going to tell us what kind of cheese is that relevant to the story? Do you know?
DAVID: 00:15:16
Yeah, it's cheddar cheese. In Scotland, they have normally cheddars like a sort of creamy white colored cheese. In Scotland, they have, they put some kind of red, I don't know what they put in it, but they have red cheddar in Scotland. Part of it was red cheddar and part of it was just normal white colored cheddar. Back to New Zealand, I got my first job in developing software with lots of other developers. That was quite an eye opener for me. I always expected that software houses would have massively high standards for code. Keep in mind that I'd just been working on software by myself in this factory in Scotland. So like moving to working with other developers, I always assumed that the standards would be high and the code would be impeccable. That's not what I found. I found that, you know, things, you got them done and when you finished them, you just, things got swept under the carpet and the technical debt built up. I didn't really like that. It didn't appeal to me. I was kind of used to having things to my standards. And I just, I cast my mind back to sort of working or reading the emails on the mailing list for Postgres. And I knew that the standards there were really high. And so I spent a few evenings sort of starting to work on Postgres again when I first started doing that job. And that's where the sort of momentum built up and I ended up sort of progressing into full time work. And I left that job and I started working for 2ndQuadrant. And that was the start of my full time Postgres work.
CLAIRE: 00:17:35
So how long were you in this job in the more traditional developer job before you went to 2ndQuadrant?
DAVID: 00:17:45
So that was a year and a half I spent there. And in that time I was like, I was going to be joining 2ndQuadrant before then. But there was like visa things like my visa was tied into my job at the time. So I had to become a resident of New Zealand before I could change jobs.
CLAIRE: 00:18:08
I understand. Okay, so how did you get connected to the team at 2ndQuadrant? Was that all through the contributions, the conversations on the Postgres mailing list?
DAVID: 00:18:22
Yeah, I, yeah, I mean, it was, I guess, you know, you're working in the public, working in the Postgres community. So, you know, people that are working in Postgres see what you're doing. And I think it was Andres Freund that originally contacted me. And then Simon Riggs contacted me and they wondered if I'd come and work for them. And I ended up doing that.
CLAIRE: 00:18:49
It's pretty wonderful for pretty much everyone that you work with now that you did that. That you said yes, did you have, was it a no brainer? Was it a decision that you made over, you know, one dinner? Or did you have to think about it?
DAVID: 00:19:09
No, I definitely didn't have to think about it. When I think back to when I first found the community, when I was working in the job in Scotland, reading those emails, I thought, oh, these, you know, I just looked at the people that were working on Postgres. I thought, you know, that's, these are like amazing developers. These, these guys are really good. And later when I was asked to go and work on that kind of stuff full time, I, you know, I had to pinch myself. It was like, it was just an opportunity I couldn't turn down.
CLAIRE: 00:19:50
There's something about you too, though. Like you said that for the first couple of years, the software that you were building it, the, now it's a cheddar cheese factory, was using MySQL, not Postgres. So you probably weren't like exposed, I imagine, I'm just guessing here, to the Postgres mailing lists and the Postgres conversations in the very beginning. And yet somehow you developed high standards from the beginning, like, but there was nobody working with you. How does, how did you do that? Is there something earlier in your life where you had high standards?
DAVID: 00:20:24
I don't know the answer to that. I don't think I have high standards for everything. I, it just appeals to me in code, especially for a code base that's as old as the one for Postgres. Accumulating things like technical debt is, I don't see that as a good future proof thing to do. And, but back to your comment about not having used Postgres much, that application that I developed, I only used MySQL for about two years. And then I migrated that application to use Postgres. So, and, and that, that, that program is still live today and doing what it has been for the last 19 years now.
CLAIRE: 00:21:20
How did you hand over the reins to somebody else when you left? Did you hand over the reins or did you wake up one morning and say, I'm out of here, I need to go travel? Or was there like a, I don't know, was it well documented?
DAVID: 00:21:40
That's a good question. When I announced I was leaving, I had to write documentation for two months. And I, I still do a bit of work for them. And to, it seems really, I never really had to do much like that. Software just seems to work. But they can still call me and I have several days to respond to them. And there hasn't really been too many urgent things.
CLAIRE: 00:22:15
Quite a nice testament. Okay. So, so of those seven years, five of them were spent with Postgres. And you're saying that that exposure to the Postgres community influenced your standards, if you will, your expectations for avoiding technical debt or, you know, what the quality of a source base should be like. Is that, did I get that right?
DAVID: 00:22:42
I, I'm not sure. Like, I don't know if it influenced or already had those. It's a good question. It's certainly like working on Postgres appealed to me because of that. So I just don't know what came first if I developed. Sort of, let's call them high standards, but, you know, it's all relative. And as a result of working in Postgres or if those existed before, I, I don't know. It's something that certainly helps to, to get stuff accepted into Postgres.
CLAIRE: 00:23:21
Yes, I can imagine it's very helpful. Whether, whether it's a nature or a nurture thing, we'll probably never know is what you're saying. Okay. So in the chat on Discord, it looks like Rob Treat dug up what might be your first email sent to the mailing list and it's timestamp 2008. So March of 2008 and the subject line is Possible problem with EXTRACT(EPOCH FROM TIMESTAMP). I don't know if that sounds familiar to you or brings back any memories, but you should take a peek at it later.
DAVID: 00:24:01
Oh, wow. Yeah, I am. I presume that was my first email. I think that's another subject that's been revisited recently with what extract returns. I don't recall the details of that. I think my first patch was around faster lookups for text searching for the position function in Postgres. And there was an item on the to-do list around using Boyer-Moore-Horspool. Sorry, it was actually using Boyer-Moore algorithm to speed up text position searching. And yeah, my patch used a sort of.. Most of the algorithm, a slight variant of the algorithm to speed that up. And that was my first accepted patch.
CLAIRE: 00:24:57
And I think it's really interesting that your first accepted patch was had to do with speed, had to do with performance, had to do with faster lookups. Right. Which is kind of what I know you for. Right. The blog post that we've collaborated on together. You wrote a blog post about speeding up sort performance in Postgres 15. Oh, and when I say collaborated, you're the primary author. Right. I just had the privilege of being the reviewer and helping optimize a few things. But sort performance, number one. And then the next blog post was what's new in the Postgres 16 query planner. And you covered, it looks like 10 different items of things that were new in that release. But many of them were performance related as well. So I'm just wondering, how can we how can we talk about that? What is it about you and performance? Did it come from the motorbike experience or was it there even before then?
DAVID: 00:26:01
I think it's because I'm Scottish and I'm cheap. So I want to be cheap with my CPU cycles as well as my money. I don't know. Yeah, it's a good question. I think I just got a buzz of making things going fast, go faster. It feels like working on a race car. You know, if you were if you're in a Formula 1 team working in a race car, you'd be all about trying to squeeze a few percent here and there for performance. And for me, it feels I've never done that, but it feels exciting like that should be. And I think that's why I've stayed interested in doing that kind of work for such a long time.
CLAIRE: 00:26:59
One of the questions that Daniel Gustafsson wanted me to be sure to ask you about is when you first started working on Postgres, you're not a query planner. And he wondered why, why did you pick the query planner? Why did you pick one of the most complicated parts of Postgres to focus on? And I'm actually not sure if that focus came in your first year or not for a couple of years. So maybe you have to walk me through that. But we need to talk about why the planner, why the optimizer?
DAVID: 00:27:36
Yeah, that is a good question. It's probably an area that doesn't get a lot of love. I think it probably came from the first job I had in New Zealand. We were using SQL Server. And I had the Postgres experience. And at the time I was starting to do a bit of Postgres stuff in the evenings. And I found that I was constantly sort of comparing SQL Server to Postgres. In regards to the query planning, and I would see that SQL Server might do something that Postgres didn't. And I think I just felt some loyalty to Postgres. And it made me a little bit sad that Postgres didn't do a particular optimization that SQL Server did do. And that's when I sort of started trying to fix those things. And I think the job in Scotland, I was doing a lot of writing SQL, writing queries, writing reports for different things. And I think I probably got pretty good at writing SQL. And I wasn't really touching the internals of Postgres at all. It's all from the user perspective. And you'd get slow queries now and again in reports. And you'd have to do something, maybe, and that might involve rewriting the query. So I think I probably learned quite a lot about when you rewrite a query, you might form the query in another way that's equivalent to give the same results. But force the optimizer to produce a plan that executes the query in a slightly different way that's more optimal. And I think when you do that sort of stuff quite often, I think you learn quite a lot about what's equivalent to what. And I think I just had an idea of what could be done in the query planner to produce a plan that executes things in a more optimal way.
CLAIRE: 00:30:14
I think it's fascinating. There's a question that came in on the chat from Rob Treat about how you learn the computing internals to be able to do optimizations on the planner and the optimizer for Postgres. And I feel like you just answered part of that question. Now, maybe there's more things. But it sounds like you're saying that your experience as a user, your experience as someone who had to rewrite queries or had to get really good at formulating equivalent queries, that that influenced your understanding of Postgres.
DAVID: 00:30:54
I guess there's probably two parts to that. There's work that I've done on the query planner to maybe have it execute the query or have it consider a plan to execute the query in a different way. And then there's also work on actually make existing code faster. And I guess the end result of those is potentially the same thing. Postgres goes faster. But how you get there is kind of different. Like, for example, a performance improvement that speeds something up during execution. Then that might be like doing something like using a different algorithm for something related to execution. And maybe that's what Robert's talking about. One of the things I did when I got home, I think it was 21, when I got home.
CLAIRE: 00:31:54
When you got home to Scotland?
DAVID: 00:31:56
To Scotland, yeah.
CLAIRE: 00:31:58
Because home is New Zealand now, is that right?
DAVID: 00:32:00
I'd say yes, home is New Zealand now, that's where I live. It's kind of confusing. Often home is interchangeable between the two places. So home Scotland.
CLAIRE: 00:32:12
Okay.
DAVID: 00:32:14
Yeah. And, you know, this was like the year 2001. So it was the start of the mass use of the internet. And my mom and brother, they had bought themselves a computer to keep in contact with me through email when I was away. It's before the days of instant messages and things like that. You know, before the days of smartphones. And when I arrived back home, this computer was there and I wanted to learn. So I ended up. Also, when I got home, it felt quite, my horizons were broadened. I'd been to places and seen a few things and I moved back to the small village I grew up in, in Scotland. So I just started seeking. I wanted to talk to people that were in different parts of the world. And I found IRC. And I sort of got back into, you know, this was before the job in the cheese factory. I think that's when I re-found programming. And I had a friend there and he had his own IRC network. And I got really interested and I wrote like a channel service bot for IRC. And I picked C to do that. So my initial choice was C++. But for some reason, quite early on, I couldn't figure out how to link to C++ files together once they're compiled. And for some reason, I decided to use the opportunity to switch to C. And I worked on that for, I was working at the time. So in my spare time, I was working on that. And I spent about a year working on this project. And that's what really got me into sort of, you know, algorithms like data structures and things in C. I learned a huge amount there, like things like hash tables and binary search trees. Because you were looking at, you know, potentially a lot of data processing, a lot of lookups that needed to be fast. The IRC network wasn't that big, but I just wanted to make this fast. And it was exciting because I was learning a lot of low level things and concepts that have sort of come back in Postgres. Like a few years ago, John Naylor worked on a project, and Tom Lane as well, I think. They worked on using a thing called a perfect hash function to have faster keyword lookups in Postgres for parsing SQL text. And they used something called a perfect hash function to do that. And it just means you don't have any collisions in your hash table. But that was something I'd done in this IRC bot years before. So I think I got into quite a lot of stuff there and I learned a huge amount about data structures and computer science topics.
CLAIRE: 00:35:58
But this was all self-taught on that computer that your mom got to stay in touch with you while you were traveling. Is that right?
DAVID: 00:36:10
Yeah, self-taught. A lot of research, you know, a lot of finding articles about different data structures. But yeah, self-taught. And that's kind of what led me to go into that course that I mentioned about Visual Basic.NET. I just really enjoyed the sort of low level stuff, you know, the back end stuff, the performance stuff.
CLAIRE: 00:36:43
The research that you were doing, you're talking about 2001. Were research skills just natural to you? Because I can't imagine that search was nearly as good back then as it is now. Or did you run into a ton of obstacles trying to get answers to the questions that you had? Or did it just all work? Were you able to find the answers to your questions?
DAVID: 00:37:19
Yeah, that's a good question.
CLAIRE: 00:37:22
You may not remember.
DAVID: 00:37:25
Yeah, I can't remember. I don't know if I had other software as an example. Like there was certainly, I would have been sort of referencing like the IRC daemon software. And I would have probably been looking at how that did stuff, potentially. And maybe that was a guide for learning. I don't know. I certainly distinctly remember looking up a certain type of balanced binary tree, binary search tree. And that wasn't in that IRC network software. So like I was finding articles on the internet, you know, about data structures. And, you know, there was search engines back then. I guess there just wasn't as many articles to find.
CLAIRE: 00:38:26
Yeah, and maybe search was better in 2001 than I'm giving it credit for. I suppose it wasn't that long ago.
DAVID: 00:38:34
Yeah, it's really hard to remember.
CLAIRE: 00:38:38
Okay, so I have so many questions that we haven't even gotten close to yet, because we're still back on early days for you. Once you went to 2ndQuadrant and you started working on Postgres, were you working on Postgres full time when you hired on there?
DAVID: 00:39:00
Yeah, so with 2ndQuadrant, it was a mix of doing support for the customers they had and also working in Postgres. I think the time split there was meant to be roughly 50/50 between those two. And I've got no idea if that's what it was. I think that my time zone, and I forgot to say earlier, thank you for moving this so I didn't have to wake up at four o'clock this morning. But my time zone in New Zealand, it's, you know, UTC plus 12 or 13, depending on the time of year, is actually really good for, you know, like, to save giving people in Europe the night shift, you could give David the day shift. So I probably ended up doing my fair share of support shifts for them. And, you know, the rest of the time, once I finished the shift, I'd be, you know, working on some patch that I was trying to get into Postgres.
CLAIRE: 00:40:05
Was that support work important or did it influence your mindset that you bring to your engineering work? Like, did it give you empathy or understanding? Because obviously you yourself had been a user. So you already had some user perspective. But I'm just curious if support work made you a better engineer.
DAVID: 00:40:28
Yeah, I think it really does. Because you see a lot of repeated problems, like people experiencing the same problem over and over. And it's kind of just like, it's hard not to want to fix those things, because, like, my motivation was to work on Postgres. And if I had to deal with a customer's problem that was the same problem as I'd seen the week before, for example, then it motivates you to want to try and fix that, to reduce the time you spend trying to fix the same problem over and over. So you do learn a lot about actual real world problems that users have. And it definitely influences you to, so you end up fixing actual problems that people have rather than problems that you imagine that people have. And you can also get that from following along in the general Postgres mailing list. You know, you get people there reporting what issues they're having. And it's always good to keep your finger on the pulse in there, I think, to see what people experience as users of Postgres. And, you know, keeps us in check for what we think we want to fix or improve.
CLAIRE: 00:42:00
The place I'm taking notes, because I had, you know, given myself a bunch of questions I wanted to ask you, where I'm writing notes right now is right next to a question that says, how did you get good at Postgres? How did you build the skills that you needed to be the Postgres contributor that you are now? And it's interesting because maybe this support work and keeping your finger on the pulse, you know, the bugs mailing list, for example, maybe those things are part of the answer. Maybe they helped you. Yeah, good.
DAVID: 00:42:36
Thank you for saying I have the skills.
CLAIRE: 00:42:42
I'm not the only one who says that. So that is a statement of fact, not a nice compliment. But OK, how did you get good at Postgres? Maybe support is part of the answer. Maybe it's not. I'm not going to put words in your mouth. So maybe enumerate all the ways, all the things you did. And this is relevant not just because people want to know your background and they're curious, but also because some of the people who listen to this podcast are trying to figure out, you know, do I want to become a Postgres contributor? And so they you know, if you've got a cookbook or a list of things that will help somebody get good at it, that's good to share.
DAVID: 00:43:23
So I think. How I got good at Postgres. Well, I think that project I had in C in 2001, 2002, like I think that gave me a lot of C skills and data structure skills and, you know, how to write C code in general. And that doesn't help me know anything about Postgres for sure. And I when I was traveling after I left the cheese factory job in Scotland. I spent I had a laptop with me and I did spend quite a lot of time reading the Postgres mailing lists while I was traveling in the evenings. And I think like I also remember reading the entire manual, I think, for Postgres 9.1 during that time. I was traveling by myself in Australia and quite often I was maybe in a very remote part of the desert in Australia. And in the evenings, quite often there wasn't a great deal of things to do. So I ended up just doing a lot of reading. And one of the things I did read was the manual for Postgres 9.1. And between that and the mailing list, I think you pick up a lot about how Postgres works. I think I wasn't really looking at the actual source code much at that point. I think that only came from when I moved to New Zealand and was doing a bit of Postgres in the evenings. I started looking at the actual C code of Postgres. So I think there's a combination of a lot of things. I got a lot of exposure to Postgres as a user when developing that application for the cheese factory in Scotland. Plus the C background for that IRC and channel service bot project. And then reading the manual and reading the mailing lists and then finally diving into the code base and seeing the inner workings for myself. And also the mailing list is full of really smart people and they have a lot of really smart things to say. So that's just such a large contributing factor to learning all this stuff, I think.
CLAIRE: 00:45:55
I think that's true for you and true for a lot of people when you get exposed to discipline, rigor, communications that are very logical or analytical or well structured. But I don't think everybody assimilates those kind of patterns. I don't know. I think you have to have that curiosity or be paying attention. Be attentive to the fact that the way in which people are communicating or the topics they're explaining, they're explaining well. I don't know. Maybe you disagree. Maybe everybody absorbs. What is it they say? They say that you should pick your friends carefully to be good influences on you and to be the kind of person that you want to be. Because your friends can bring you up or bring you down. So maybe what you're saying is that the folks on the mailing list set a good example and brought you into that world.
DAVID: 00:47:10
I think reading those emails and just when you read those in the pgsql-hackers mailing list, you can tell the project has high standards when you see a patch being reviewed. And just how much detail a reviewer would go into checking that patch and seeing that it is correct and does what it is meant to do. It's hard not to be influenced by that and just develop a high standard. And if you want to succeed in Postgres, then I think you really need to adopt that mindset. When I think back to my first job in New Zealand, when I didn't work on Postgres, the standards there were just different. There was a peer review system, but it just didn't seem that thorough. And things were committed that probably were late and they just got pushed in at the last minute to get them in because somebody was waiting for them and there was a customer paying that company money. And that doesn't exist in Postgres. I mean, of course there's companies that are making money from Postgres, but because the people that are actually working in Postgres are from lots of different companies, if somebody that's reviewing some work that I've done works for a different company, then they don't know or care that the company I work for has a customer waiting for this feature. So we're sort of less motivated by customer needs. We don't rush things in Postgres to satisfy a customer that an employer has. I think that keeps the code cleaner, not rushing things in at the last minute.
CLAIRE: 00:49:22
Okay, so certainly back to how you got good at Postgres and again with an eye toward if somebody were looking to become a Postgres contributor, how might they do it? I guess I should qualify this topic with a belief that I have, which is that there's no one path into Postgres. Like we're here today to talk about your experience and your journey, but there are other journeys and there are other paths. So please, whoever's listening, don't think that David's answer is the only answer. But David's answer is useful. And so you talked about how you learned to program in C, you talked about reading the mailing list, you talked about reading the manual, you talked about your experience as a Postgres user back in the cheese factory in Scotland, and particularly you were rewriting SQL queries to try to deal with slow query problems. Are there any books or tutorials or blogs or like, is there, was there a Bible that you also read that you would recommend to people who want to become Postgres developers?
DAVID: 00:50:35
One book that I did find very good, it wasn't specific to Postgres. It's called The Art of SQL or The Art of SQL. And I've forgotten the name of the author. It's a French guy. I thought it was a very well written book. The chapters were broken down. There's an old book, The Art of War, and I think it breaks the chapters down to various techniques. And he had done this book in a similar sort of way, like fighting on multiple fronts was talking about concurrency and ways to deal with that better and the things you can do to write your queries in a better way. And I think that book was, it really just changed my perspective on how to use a database. It was just, for example, like one example that I do remember was like checking user credentials during a login. I had written the application, you know, you do a select query to query the table that stores that information and to validate the username and password are correct. But that guy's approach to that was to do an update statement. So one of the things, the application I programmed during my time in the cheese factory. There would be a column to mark the last login time for a user. So instead of doing a select query, this guy said, do an update query and put the details in the where clause of the update and check if you got one or zero rows returned. And if you got zero rows, then people don't need to know the reason why they couldn't log in. You don't want to say it's incorrect password because that might give something away that they found a correct username, you know, for somebody malicious trying to brute force something. And so it changes. Instead of got two operations doing a select then an update, you just do an update. And it's just small tips like that that I found really interesting. And it was a perspective that I hadn't really thought about before.
CLAIRE: 00:53:01
So while you were talking about this on the live chat that happens in parallel, people were discussing two different books. There's The Art of PostgreSQL written by Dimitri Fontaine, who is French, but there's also The Art of SQL that's written by Stéphane Faroult, who is also French. And what I'll say when I look at The Art of SQL, it does say that his book named after The Art of War by Sun Tzu contends that. So it does seem to have that connection to The Art of War. So is that the one you meant?
DAVID: 00:53:32
Yeah, that one.
CLAIRE: 00:53:34
Okay. Okay. So not Postgres specific, but really helped you. And when did you read this? Where were you in your journey?
DAVID: 00:53:45
In the cheese factory in Scotland. It's mostly from a user perspective of Postgres. That's not going to be a useful book to read if you want to get into the internals of Postgres. It's really about SQL.
CLAIRE: 00:54:03
Yeah. I mean, which is the way in which users interact with and take advantage of Postgres. So it's important, obviously. Okay. Any other books or blogs or tutorials or things that you have that were useful to you in your journey or that you find yourself recommending all the time?
DAVID: 00:54:27
Well, I think more recently, I've been getting into sort of low level CPU stuff, trying to educate myself a little bit more around how to write more efficient codes. So it runs faster on a CPU. And there's a book by Fedor Pikus and the title, I can't remember the title at the moment. Somebody might be able to look that up. Fedor Pikus. And I find that books very good. He does a lot of low level benchmarking and CPU profiling too. And he talks about branchless programming and really demonstrates why certain code is faster. I've read maybe half of that book at the moment and sort of slowly progressing my way through it. I highly recommend that book. It's very good.
CLAIRE: 00:55:35
Okay. I haven't found it yet, but I'm waiting for somebody to pop it up. Is it The Art of Writing Efficient Programs?
DAVID: 00:55:45
Yes, that is the one.
CLAIRE: 00:55:47
Okay. All right, good. We have a recommendation. But you haven't gotten to the ending yet. So you don't know if the conclusion is going to make you happy or not. I'm teasing. That's really a problem more with fiction than it is with nonfiction. Right? Where you like everything in the book, you like all the character development, you like the plot until you get to the ending. And you hate the ending.
DAVID: 00:56:15
Yeah, I'm holding out for that twist at the end.
CLAIRE: 00:56:19
Okay, so it's, I was hearing you say Theodore, but it's Fedor, F-E-D-O-R is his first name. And the last name, Pikus, is P-I-K-U-S.
DAVID: 00:56:33
I probably butchered the pronunciation.
CLAIRE: 00:56:36
If you were saying it wrong, or I didn't hear you properly, that could be it too. Okay, awesome. Two book recommendations. I appreciate it. Anything else that you found really, really useful to your developer learning journey?
DAVID: 00:56:58
I've got a couple of blogs apart from that. And this is a lot of sort of low level CPU blogs that I'm quite interested in. Give me one sec to.. I like this Tony Finch. He's got a blog and the website's dotat.at. And dot is spelled out. D-O-T-A-T dot A-T. And he talks about quite a lot of low level stuff like simd related stuff, for example. He's got some stuff on there about using simd within a register, which is something I didn't know until a few years ago. And I recently committed something similar related to Postgres. In fact, it was just yesterday. And I think, you know, keeping up with what he has to write is, I find it very interesting.
CLAIRE: 00:58:04
There's a quote on the chat that I really like that I think is from Simon Willison, who was actually a guest on the very first episode of this podcast back when it used to be called Path to Citus Con. And the quote "is in this highly distracted short form world, blogs continue to outperform". And I don't know, I'm a big fan of blogs. When I'm trying to figure something out at two in the morning, blog results, they tend to pop on the searches that I do and the research that I'm doing. And they can give me something that is, you know, five pages, six, I'm using pages. Who uses pages anymore? But they can give me something that's sufficiently detailed and deep to help me understand something, but doesn't require me to go read a whole book in the moment, which is not something I can generally accomplish at two in the morning.
DAVID: 00:58:56
So, yeah, I think that's a very good point. Like it's obviously places for reading books, but if you're working on something and you're stuck on something, then you're probably not going to read a book to get yourself unstuck. But a blog, you might read that.
CLAIRE: 00:59:15
Yeah, and apparently that quote in this highly distracted short form world, blogs continue to outperform, that came from Aaron Wisling, and he was paraphrasing something similar that Simon Willison had said. So I got to get my attribution set up properly. Well, speaking of blogs, obviously we mentioned two that you've written about Postgres in the last two years, both of which were very popular. If I remember correctly, I think they both hit front page Hacker News. So I, not to put you on the spot, but to put you on the spot, am really curious, like whether you have a blog in your head about some of the new stuff that's in Postgres 17, and whether that blog will transfer from your head onto paper or onto a blog.
DAVID: 01:00:05
Yeah, I think so. Like that latest blog that I did, it was around changes to the Postgres 16 query planner. I think I've got to write a sequel to that for Postgres 17. It's something that's evolving, still evolving, and I think the amount of people that are now working on the planner has increased. There's quite a lot of changes going in recently, and I think, you know, providing a bit more detail about what's changed, a few examples. You know, for somebody to read the release notes, there's a lot of information that has to go in the release notes. You can't provide all the detail that people really want, in that you have to keep them realistically readable. So like going into a few of those, like in terms of query planner changes, I think that can be quite useful. If you turn that into a few examples, like that blog that I showed, an example of how the Postgres 15 query planner would optimize something, and then it went on to show what had changed in Postgres 16. And I think if you're a user and you're thinking of upgrading, it's good to show SQL and, you know, query plans, things that they're used to looking at. So that would be one thing.
CLAIRE: 01:01:35
And definitely some people who reached out to me who really liked the structure of that Postgres 16 optimizer blog that you wrote. They loved seeing the PG 15 explain output and the PG 16 explain output, as well as the query itself right above that. And so you were, the phrase I often use is, I like to show not tell. And I think there's a big difference between someone just telling someone how something is going to work versus showing it to them. And your code examples and output examples really showed people. So, yeah, I think it'd be great if you copy that technique again.
DAVID: 01:02:20
I'm going to have to do it every year now.
CLAIRE: 01:02:27
I don't know about every year, but at least do it for Postgres 17, one step at a time. I used to be a runner and my dad would run with me on weekends and sometimes I would just be tired. You know, you run eight miles and you're getting exhausted and you just want to take a break. And he was always pushing me like, okay, no, just go to that tree about a quarter mile ahead. And then we get there and I'm like, okay, I need to take a break, dad. He's like, no, no, look, let's just go to the corner. And then we get to the corner and he's like, okay, just go to the next building. And so, yeah, all I'm going to ask you for right now is the Postgres 17 blog post. And then we can have a conversation about what the tree is after that.
DAVID: 01:03:07
Okay, right. Now I see how your mind works. Okay.
CLAIRE: 01:03:12
All right. Did we, we didn't really explore whether there's a connection between the performance buzz that you get, like when you make something faster and you, you, you suggested that maybe there's a connection to your motorbike days. Right. And how you used to enjoy, you know, working on the bike. But I'm curious, like for the other time that you spend outdoors, because I know sometimes I can't, if I wanted to, I couldn't reach you on the weekend because you're going to be in the mountains, backpacking, whitewater rafting, hiking, doing whatever you're doing. There's probably no cell signal, right? You really enjoy the outdoors. Is that, is that time away from the computer an important component of your ability to then come back and sit at your desk and like architect solutions in this complex system? Or is it completely unrelated?
DAVID: 01:04:10
I think it helps. Like I've certainly, I've been in some remote mountain hut somewhere and I've been thinking about some problem maybe while I'm walking. Like, and there's definitely been ideas generated and there's times where I might go away for the weekend and yeah, yeah, there's no cell signal. I mean, it's improving, but primarily there's none. And like, I've definitely come back with ideas and, you know, I might come back on Sunday evening and I'm like, I just, I need to check something. Like I need to see if something in the Postgres code is the way I think it is in my head when I'm away. And there's certainly a lot of things that have turned into actual patches that are now in Postgres as a result of things I've thought about when I'm in the mountains somewhere. Don't ask me what specifically, but this definitely has happened.
CLAIRE: 01:05:16
You know, for a talk that I'm going to give at PGConf.EU later this year in Athens, it's an analysis of all the contributions to Postgres in the Postgres 17 timeframe. And it's both code and also non-code. And I'm collaborating on the research with Daniel Gustafsson, who you know, obviously, another Postgres committer and contributor. Anyway, what's my point? I know I have one. As we look at the commit messages that people submit, I don't know, maybe there should be a new piece of metadata that gets added, which is like source. Like, where did this idea come from? And in your case, it would be like the Southern Alps or something like that. And then you could capture this data and we can look back on it in five years and see how many of your patches had their source when you were in the outdoors and then we'll know. Yeah, it'd be interesting. Maybe not worth putting in commit messages, but maybe to track that personally, maybe. Maybe for my own optimizations or something. And I could maybe use it to, you know, convince my manager to give me that leave. Is KK listening right now? I don't know. Is he on the chat? I'll have to go look. I'm curious, though, like when I have an idea, I'm genuinely concerned that I will lose the idea before I can write it down. I feel like really creative ideas can just slip right through your fingers. And so I try to make sure that I always have like a little I have a mini notebook in my purse just in case my phone is dead and I can't write it down in the notes app on my phone. And even on my desk, like maybe my phone's in the other room, maybe the computer's crashing. There's post-it notes where I could scribble if I absolutely had to. So I'm a big believer in the yeah, don't assume you're going to remember it later because you won't. But it sounds like you think of these things while you're off for the weekend and you remember them completely like they don't ever slip out of your recollection.
DAVID: 01:07:37
I sometimes do write them down. Sometimes I don't feel like I have to. Certainly there's been times where some ideas maybe flashed into my head and I might spend the entire remainder of the trip walking along thinking about that idea. It's pretty hard to forget when you spend your entire day thinking about it. But there's also the ones that maybe you think about more briefly. And I will maybe type those into my phone somewhere and just to make sure that the idea doesn't disappear.
CLAIRE: 01:08:13
Yeah, just disappear into thin air. And then you're like, "Oh, I knew, I knew. I had it. I had it." My ideas can be kind of wacky too. It's not, if it's not about solving a particular problem, which therefore if the problem is in front of you, then maybe the solutions will get remembered. But they might be something just unexpected. Anyway, and so therefore if I don't write them down, they're gone.
DAVID: 01:08:40
I think if nobody ever had a wacky idea, the world would be a pretty different place today.
CLAIRE: 01:08:46
And it would be boring, wouldn't it?
DAVID: 01:08:49
Potentially. I think we'd probably have a lot less technology if nobody had a crazy idea ever.
CLAIRE: 01:08:58
Question for you. I was listening to a Postgres FM podcast episode the other day while I was out for a walk. And that's the podcast that is hosted by Michael Christofides and Nikolay. Oh, I have trouble pronouncing Nikolay's last name, so I'm not even going to try. It's an awesome podcast, much shorter episodes, more focused on the features of Postgres. But anyway, in there, Michael ended up talking about the priority or the trade-off between performance and reliability and correctness. So how do you think about the priority of performance work versus the priority of reliability and correctness?
DAVID: 01:09:41
Obviously correctness has to come first. You can optimize something as much as you want if you don't have to provide the correct answer. You can make it infinitely fast. So in terms of priority, obviously correct results. If you're talking about the results of a query, then we can't start returning incorrect results to favor performance. So that's definitely priority one. Not crashing is very important. And you have to fit performance around those two things. Performance is quite hard as well, I think because Postgres is such a flexible piece of software. And when we write it, there's so many different use cases for using Postgres. It's quite hard to find typical use cases. And you tend to, like, if you want to work in a performance patch, you might find the best case for this performance work. But you don't necessarily know the best case is a common case. And I think that's why keeping your finger on the pulse from the Postgres general mailing list, to find out what problems people are actually experiencing. And make sure you try and fix those problems and don't fix problems that are just made up in your head or, you know.
CLAIRE: 01:11:22
In your ivory tower. In your Southern Alps.
DAVID: 01:11:28
Yeah, I don't pretend to always fix, you know, problems people are actually having. But, you know, the more you can sort of keep check on that general mailing list. And, you know, listening to what users have to say. You know, the more chance you've got of actually fixing problems that are actually real problems.
CLAIRE: 01:11:51
One of the things we talked about when we were getting ready for this episode is we talked about what I call the toothbrush test. And anybody who's a regular listener to this podcast has heard of the toothbrush test, which I first learned about when I was 21 years old. And it's this notion of when you're brushing your teeth in the morning, which you should be doing. Not everybody does, but whatever I do. Like, are you looking forward to your work? Right. Are you is your avocation and vocation connected? Are you looking forward to going and doing whatever it is that you do in your case for Postgres at Microsoft? So does your work pass the toothbrush test?
DAVID: 01:12:35
Yeah, absolutely. I think like living in this New Zealand time zone, quite often most of the discussions that happen on the Postgres mailing lists or when I'm sleeping, maybe not most of them, but a lot of them. So quite often when I wake up in the morning, I maybe don't know exactly what I'm going to be working on that particular day. And but when I check my email, if I've had a response to something, then that can quite often, I quite often decide from there. And quite often that is actually me reading emails when I'm still contemplating getting out of bed in the morning. And quite often the plan gets formed before I get out of bed. So I'm pre toothbrush.
CLAIRE: 01:13:33
Got it. Pre toothbrush, but looking forward to it. And I'm dropping a bunch of the mailing lists links into the show notes just to make sure that they they end up there. Because it sounds like they were important to forming the kind of Postgres developer you become. But it also sounds like they're part of your day to day.
DAVID: 01:13:58
I think the emails I'm talking about are primarily maybe people's responses to things I'd written. And that might be working on a particular patch. And that might be somebody's reviewed something I've worked on or I've reviewed something they've worked on and they've responded. And then that might involve me doing more work on my patch or me doing more review on their patch.
CLAIRE: 01:14:28
I'm curious what software you use for email list management. There's a lot of email.
DAVID: 01:14:42
Yeah, there is a huge amount of email traffic. I don't have anything too special. I just I use Gmail and I just use the web interface for Gmail. I actually mostly like it. I can't fault it enough to want to change away from it. And I'm used to it, which is the important part for me.
CLAIRE: 01:15:10
My experience with Gmail is that search on the desktop is dramatically better and more correct than search on my phone. Is that a clear problem or is that your experience as well?
DAVID: 01:15:25
I have not noticed it being better or worse on any of the two. I sort of mix between searching on the Postgres mailing archives and on my email. It is sometimes slightly frustrating on the Postgres emailing search because the timeout. I think as a committer you need to sort of quite a lot of archaeology to find out where certain decisions were made. And it might predate me working on Postgres, so I might not have some old email. So I might consult the archives from, you know, 15 years ago or something like that. That's useful.
CLAIRE: 01:16:14
All right. So if you could time travel and give advice to your younger self about getting started as a developer or getting started with Postgres. What advice would you give yourself? Is there anything you wish you'd known then?
DAVID: 01:16:36
I mean, that is a good question. I think it often makes sense to sort of try and utilize your strengths in what you do. And you know, you shouldn't not learn new things as a result of doing that. But I think if you can utilize your strengths and you maybe stand out. I think if it comes to somebody that wants to maybe get involved in working on Postgres, I think that because there's quite a lot of people doing that at the moment, I think we probably have some bandwidth issues when it comes to getting people's stuff committed into Postgres. I think because we're growing quite quickly, there's just a sort of more newer people. The ratio of new people to experienced people is just probably not exactly what it would be ideally. So I think one thing that somebody new that wants to submit something, a patch to the Postgres mailing list or something, is try and make your work stand out. Try and prove that you've done the research and you've looked at the archives and you've done all your homework. And try and not make it look like you've woke up this morning and come up with this idea and written a patch. I think when people come and they've done all their homework and due diligence, I think it's just easier. The bars, you have to do less as a committer to get those things into shape. And I think that might help people have a better experience in the community.
CLAIRE: 01:18:42
That's like magic to my ears to hear you talk about just because, I don't know, years ago I worked with someone. And gosh, this would have been late 2000s, mid 2000s, I don't know. And his goal was to get stuff off his plate. And it was like oil and water for me because I felt like, well, wait a minute. You're working with other people. When it goes off your plate, it's going onto these 50 other people's plates. And don't you want to make it more efficient for them? If what you communicate is ambiguous or unclear, that means 50 people get stuck trying to figure out what does this mean? What am I supposed to do? How do I act on it? So anyway, I like, of course, what you said about trying to make your work stand out. But I guess I was also hearing this fact that you need your work to also be clear. Maybe I was hearing what I wanted to hear from what you were saying. Was there, did Melanie Plageman give a talk last year at PGConf.EU about, let me go look it up. I think it was like techniques or suggestions or tips for making your Postgres patches more likely to get committed or accepted or something like that. Does that ring a bell to you, David?
DAVID: 01:20:16
Yeah, I know that Samay Sharma also talked about something along those lines.
CLAIRE: 01:20:27
I found it.
DAVID: 01:20:28
I don't know if he did a talk or if he certainly gave a lot of feedback around, you know, people new to the experience of somebody that's new to the Postgres community.
CLAIRE: 01:20:37
Okay, I found Melanie's talk. It's called making your patch more committable. And the idea is that if you've ever written a patch that stalled out on the mailing list, then this talk is for you. And so she walked through specific ideas and tips and things people can do to make their patch just more actionable, more likely to get committed. Okay.
DAVID: 01:21:02
I think the people should probably watch that if it's available, because Melanie has had quite a lot of success and what she has been doing has worked for her and she's now a Postgres committer.
CLAIRE: 01:21:19
Yeah, as of I think it was April of this year, 2024 for Melanie Plageman and Richard Guo were both announced as the newest Postgres committers, which is very exciting. And in fact, yeah, Melanie is going to be a guest on this episode next month, which we'll dive into in a second. Okay, so is there anything I didn't ask you that you really want to talk about, about your journey as a developer or into Postgres?
DAVID: 01:21:50
I don't think so. I'll probably think of something later and kick myself.
CLAIRE: 01:21:59
Well, I think we're going to wrap because we're almost at an hour and a half and you know, it's not set in stone. We don't have to wrap. There is a question I didn't ask you, which maybe you're saved by the bell, unless you actually do have a story you want to tell. But there's this idea. I first got exposed to it at FOSDEM last year, at the PG day that was at FOSDEM, where I think one of the engineers gave a talk that was an LFMF talk, Learn From My Failure. And I just thought it was so powerful because like everybody was paying attention. Everybody could feel for him as he told his story. Right. Because it was it was a painful failure. And but we all did learn from it. I think people don't talk about failure enough. Right. We try to stay away from it. It's awkward. It's uncomfortable. We don't feel good about it. And yet it can help others when we do share it. So anyway, I'm curious. I had I think I had told you I might ask this question. Did you come up with a story you wanted to share? And if not, you're saved by the bell.
DAVID: 01:23:13
So when you started talking about that, it made me think of PGCon in 2019, the last one before COVID times. I remember it was Melanie Plageman that did a talk on failed patches for the query planner in Postgres. And she had some statistics to share, and her point was that mostly like query planner stuff's hard and the failure rate for submitting patches and having them rejected is quite high. And I think she, Melanie, did a good job of summing up all my failures on that talk, because I think there's not a huge number of people submitting patches for the query planners. Like a good proportion of the ones that she was talking about, I think, were my patches.
CLAIRE: 01:24:10
And so we should all go look at her slides, and then we'll get some visibility into some of your failures. But were those really failures? Like, isn't it the case that you have to put forward proposed patches and you can't possibly expect them all to be accepted? Like, if you wait for the perfect patch requests, wouldn't we all still be waiting and nothing would be getting improved?
DAVID: 01:24:38
I mean, yeah, I guess it's hard to give any specific advice about that, because, you know, like if you talk to some entrepreneur, they'll probably tell you that, you know, you just have to keep trying things until you succeed. And I earlier said that maybe that wasn't always the best thing to do for the Postgres community. I think that's primarily due to just due to the volume of things that get submitted to the community.
CLAIRE: 01:25:15
Okay, well now I need to go find this PGCon 2019 talk about failed patches for the query planner, because I'm curious now.
DAVID: 01:25:26
I've definitely had a lot of failures.
CLAIRE: 01:25:30
And a lot of impact, a lot of positive impact.
DAVID: 01:25:36
I think primarily failures are, I think I could probably attribute most of them to being maybe slightly too excited about some change and thinking it's going to be great. But I've sort of let that excitement sort of curb the research I should have done into if this is a good idea or not. And I imagine that happens for a lot of people. I think having something accepted into Postgres, it's quite an exciting thing for somebody that's maybe never had that before. Because, you know, it's a well used piece of software. And the thought of maybe having your name in the credits or something is, I think it's definitely appealing. And I've definitely been victim to that probably, you know, my early days of working in Postgres, just letting the excitement get in the way of doing the proper homework.
CLAIRE: 01:26:38
All right, well, David Rowley, I have enjoyed this conversation, as with all our conversations. But I've enjoyed you being willing to have this discussion in public with a live audience here on Discord. And this episode will get published in a couple of days. So the rest of the world will get to listen to it by Friday of this week. I want to thank you so much for joining us.
DAVID: 01:27:08
Thank you for taking the time to talk to me and giving me the chance to tell my story.
CLAIRE: 01:27:13
I love it. And I know other people are going to enjoy listening to this. I also want to let our listeners know that the next episode, episode 19, can you believe 19 episodes of this monthly podcast? It's going to be recorded live back in our normal Wednesday at 10 a.m. PDT time slot. But it's going to be in the third week of September. So Wednesday, September 18th. And our guest is going to be Melanie Plageman, who we just finished talking about. And the topic is Becoming a Postgres committer. So please mark your calendar with aka.ms/TalkingPostgres-Ep19-cal. And that'll give you a calendar invite that has instructions on how to join, etc. And then in October, episode 20 is going to be with Tom Lane. Tom is also a Postgres committer and contributor. And that live recording will be on Wednesday, October 9th at 10 a.m. And Tom is going to talk to us about how he got started as a developer and in Postgres. So you can also mark your calendar for that October episode with that same syntax, aka.ms/TalkingPostgres-Ep20-cal. You can also get to all past episodes of the podcast and as well as links to subscribe on whichever your favorite podcast platform is at TalkingPostgres.com. And before we leave, if you have enjoyed this conversation, please tell your friends in person, on social media, in DMs, however you share recommendations to your friends and your followers. The hashtag is #TalkingPostgres, all one word, and word of mouth is absolutely one of the best ways to help people discover a podcast that will hopefully delight them. A big thank you to everybody who joined on Discord, too, and participated in the live text chat.
