Talking Postgres with Claire Giordano

My Journey to Explaining Explain
===

CLAIRE: Welcome to Path To Citus Con, the podcast for developers who love Postgres, where we discuss the human side of open source databases, Postgres, and the PG extensions. Thank you to the team at Microsoft for sponsoring this community conversation about Postgres. I'm Claire Giordano, and today's topic is all about My Journey to Explaining Explain.

And I am so excited to introduce Michael Christofides. Who is the founder of pgMustard, a Postgres company based in the UK. And he's also co-host of a great podcast called Postgres FM. Michael has worked in, around, and with Postgres for seven years. Welcome, Michael.

MICHAEL: Hey, Claire. That's kind of you. Thanks so much.

Thanks for having me.

CLAIRE: I'm glad you're here. All right. Let's dive in. I have so many questions for you about how you got into Postgres and why you founded a Postgres company, what you do and of course, I want to talk a little bit about your podcast too. You are, believe it or not, the first podcast host that we have had as a guest on the show.

So I'm a tiny bit nervous. You might be judging me.

MICHAEL: Oh, absolutely not. I know how difficult it is. And as a loyal listener of yours I've told you in the past, I've listened to every episode. I wish there were more podcasts, more Postgres podcasts specifically out there. So yes, you'll only ever get encouragement from me.

CLAIRE: Yeah. And I love hearing from people when they say that "I've listened to every episode". We're here to talk about you, but remind me later in the show, if you can to tell you a story of something that happened at PGDay Chicago last week, but let's go there later. I want to start with you.

So I thought we would start with your very first encounter with Postgres. When was that? What were you doing and how did you get started with it? Do you remember?

MICHAEL: Yeah, good question

CLAIRE: Or do you think you've known about it since you were two?

MICHAEL: Definitely not. Actually that might be around when Postgres started, which is, would be anyway so no, definitely not that early.

I was out of university or college. I'll try and Americanize my answers. I worked at a company called Redgate or about six months after graduating. I ended up working at a company called Redgate who made tools for developers and database administrators, but mostly for Microsoft SQL server SQL servers, as it's often called.

And as part of that, we had customers who wanted the same, they would quite often ask, do you do the same product, but for Oracle? Would be the normal question. Do you do the same product, but for MySQL? And this was back in, when would this have been? 2010, early 2010, but, it probably wasn't until like a year in that I started hearing Postgres crop up, you know, people starting to ask, it started to become, I started to become aware of it basically, and I think that's not a coincidence, I do think that was roughly when it was starting to be published.

So, yeah, a little bit more mainstream people were, including SQL server customers, were considering putting new projects on Postgres. There were definite business cases for doing so the features were catching up enterprise wise.

So I don't think it's an accident. And then I kind of, then that got put on kind of extreme mode for me because I ended up running the team that we had internally that we're porting some of our most successful products over to Oracle, like to support Oracle and have we also adopted a couple of tools for MySQL as well. So our little small team, you know, in a company of 300, our little team of about eight or nine we're running the these products for Oracle and MySQL.

So we were the natural place for people to come and ask. Are we going to make a Postgres version? Can we make a Postgres version? Should we? That kind of thing. And I, sadly, I was never successful in, in my endeavors to to make that business case. But yeah, that's when I started, first started coming across Postgres was in my five years there.

And then when I left Redgate, which was based in Cambridge, UK, and moved to London to GoCardless and they are a payments company, it was quite early days for them back then in 20 late, late 2014. And they ran Postgres in production at quite a decent scale by then, but not, like, nothing compared to what they are now.

And the team loved it. They were really kind of, they, they used to blog about it that I, that was infectious, that really rubbed off on me. And that was when I realized it wasn't just large companies moving workloads over to Postgres for cost reasons. It was also startups choosing it because the technology was great and, and choosing it over MySQL for a bunch of reasons.

But yeah, that, that was when I thought, you know what, this, this is a cool product, cool platform, very, very open community, very, very giving community, lots of positives, a place that I'd like to be long term, basically.

CLAIRE: Yeah, it's, it's really interesting, this, this idea that people can love a database.

Before I got into the space, I wouldn't, I wouldn't have believed it if you told me that because you know, it's a database, it's just a database. There's lots of databases, what's to love, but people who work in or use Postgres, a lot of them love it and you use the word love. So that's why I'm riffing off of that.

MICHAEL: And it's a good point. I think there is something to that and it's part, another reason I chose to make products for Postgres is because the people using it tend to love their jobs. And that might sound, I guess, most of our audience are technical. So a lot of them will have chosen this as a career and will love what they do, but lots of people out there in the world don't love their jobs.

And I have worked at businesses where we're serving customers that don't love their jobs and it isn't as rewarding. You don't get the same feedback. You don't get the same, you know, if you do something great, you don't get quite as much positivity, but if you do something bad, you don't get quite as much anger.

So I love that though. I love being held to that high standard. And I think I really enjoy the prep, like the impressing people that hold you to high standards. I find a lot of like satisfaction in that and it yeah, it's a love hate thing and I think the database thing is also you can see it from the flip side I think a lot of people that love Postgres have had previous experiences with databases that they let's say do not love so for yeah for one reason or another so I think there's also a nice like, it's easy to love something if you've had previous experience of something that didn't treat you so well.

CLAIRE: I had this teacher in high school. It was just crazy. I do not remember most of my high school teacher's names, but I remember his. It was Mr. Blanchard. And he wore a bow tie every day to school to teach. And he was very fond of saying that his vocation and his avocation were one in the same. And that was his wish for all of his students.

And most people, many people don't get that in life. Like you said, they don't love their job. They're how they earn their living and what they like to do are not one in the same. Right. And anyway, that always stuck with me that desire to have meaningful work that I could both enjoy as something to do, but also be the way I make my living.

So it's kind of a nice thing when you have it.

MICHAEL: Yeah, absolutely.

CLAIRE: I do think you're right. I think a lot of people in the Postgres world do have it, which is kind of cool. Okay, so you studied mathematics in college. That was your, what do you call it? A major? No, you don't. What do you call it in where you went to university?

MICHAEL: Yeah, good, good research. We have joint degrees sometimes, but they're more the exception rather than the rule. So we tend to just go to university to study one subject and we can take some classes in other related or sometimes unrelated subjects, but it's more common just to, you know, I only study one subject start to finish.

CLAIRE: Okay. So mathematics is what you focused on. And I guess my curiosity is where databases were any computer science classes, part of that field of study for you.

MICHAEL: Yeah. Yes. Not really is the, is the honest answer. We had to do, we had to do like basics of. So the first year I don't think we got much choice at all.

It was a bit of pure maths, a little bit of statistics, and a little bit of mechanics. And I think in the second year I did some statistics that involved a little bit of programming, a MATLAB type thing. So there was a little bit, but it wasn't computer science for sure. It was very much a little bit of programming for a very specific goal.

CLAIRE: All right. So really your focus on databases started after you were out of university and when you were at Redgate, so Redgate wasn't just where you first started to learn about Postgres, but it was where you really started to go deep on databases, right? All together.

MICHAEL: Oh, yeah, absolutely. I got very lucky.

Like they, I, what caught my eye about Redgate was just, was actually their slogan. They, it was Redgate software, or no, Redgate tools at the time I think it was called. And then it said, "ingeniously simple software", something like, it was one of those ways around. I can't remember if it was Redgate software or "ingeniously simple tools".

That actually sounds funny.

CLAIRE: That sound better? Redgate software or ingeniously simple tools. I like that better.

MICHAEL: I don't think they're using it anymore, but I fell in love with that as a slogan. I really enjoyed the idea that you could differentiate your product on simplicity.

I think perhaps it's the mathematician in me, but I love simple, elegant solutions to problems and would sometimes annoy my housemates by throwing away some coursework. Cause I thought I could do it simpler. I worked out a way to do it simpler, even though it was done, worked out a way to do it better.

And in software you can be rewarded for that. And it never crossed my mind that that was true until reading that slogan.

CLAIRE: Maybe that's why I liked you right away when I met you. You know, there's lots of ways to think about the different attributes that like we humans have and our personalities and in the way we do things.

But one of the things I really like is when I need a kindred spirit who does like to find a way to do it better, who is constantly, like, in search of excellence or in search of how could we improve? How could we make this more efficient? And doesn't. What's that phrase? We have a phrase in US English at least, which is like good enough for government work.

It's a horrible phrase. Like what does that say about governments? But I can't stand that attitude of good enough for government work. And so anyway, I love that you threw out coursework and did it simpler. That's great.

MICHAEL: Yeah, maybe not the smartest move ever. But yeah,

CLAIRE: Well, when you lose sleep, it's probably not the smartest move.

Right?

MICHAEL: Yeah. Yeah. I did want—before we move too far past it..... I the way you asked that 1st question, the 1st time I ever came across Postgres was super interesting. And I'd be curious on your answer to that one as well.

CLAIRE: That's a good question. And I didn't I didn't I'm not prepared for it. I think I probably came across Postgres.

And don't recall and don't remember the first time.

There's a German term for that where maybe you've been exposed to something over and over, but you've been blind to it. You've missed it. You've, you haven't retained it. And then all of a sudden it sticks. And then you feel like you're seeing that thing, that word everywhere.

And there is a wonderful German word for that. And I don't know if anyone in the live text chat knows what that term is. But the, the first time that I started to go deep that I started working with Postgres is when I joined Citus Data. So that would've been early 2017. And, and I actually went through an interesting, like six month period of having multiple invitations, multiple nudges to go meet the team at Citus to go interview with the team at Citus.

And a couple times I passed. And it was kind of like, you know, I'm not, I'm not a database person. You know, I'm not sure this is the right space for me. I'm not sure this is the right job. So I didn't go have those discussions. And then so, like, the folks at RedMonk, Steve O'Grady had. Well, I met Craig Kerstiens at a RedMonk event.

He's like, oh, you should come talk to us. We have an opportunity. And I didn't follow up on it. And then a month later, Steve O'Grady, one of the founders of RedMonk, which is my favorite developer analyst firm on the planet he sent me an email and said, I'd like to introduce you. Are you interested?

And I passed on that. And then I was I think having coffee with Anil Lakhani and in downtown Palo Alto at Blue Bottle Cafe, which is a fun little place. And yes, espresso was involved and he's like, what, you haven't gone to talk to Craig, you haven't gone to Citus, you need to go meet those folks.

And so then I reached out and you know, the rest is history. So what is that?

MICHAEL: It's a wonderful story. Yeah. Eight years or so.

CLAIRE: I'm so glad I did it. Yeah. Seven, seven plus years unless my math is off by one error. Okay. So let's fast forward to the present day. You are the founder of a Postgres company called pgMustard.

So before you tell me about how and why you founded pgMustard, maybe just give us the elevator answer of what is pgMustard?

MICHAEL: Yeah, sure. So it is a web visualization tool for EXPLAIN ANALYZE that helps people review and Postgres query plans. And hopefully speed them up. That's actually the opinionated part of it.

It very much assumes you're looking at a query plan because you're trying to speed it up. Which is a fair assumption most of the time. But if you're looking at a query plan for any other purpose, it would actually be worse to look at it through pgMustard.

CLAIRE: Okay. And why and how did you found this company?

MICHAEL: Oh, good question. And, and by the way, founder makes it sound like it's perhaps bigger than it is, but I, yeah, so it's mostly just me. I've been working with one other person over the past five years, but that person has changed a few times. So it's, it's always been two of us, which is nice. And it's a fun little team, but yeah.

So do you say why I've managed to forget the question?

CLAIRE: Why and how, which are two separate questions. Yeah. And I combine them, which you're not supposed to do, so I apologize for that. Let's start with why.

MICHAEL: Yeah. So I was basically through my career, I'd ended up in, in product management type roles.

I really love product work. I'm very opinionated, but to a fault, but also, I guess it's definitely a strength at times and I really like taking ownership and getting things done and that suited product type work and companies, when you're a product manager, you get given a lot of autonomy, but ultimately you can still get overruled.

There's always somebody who can say do you know what you've got a great team there, but we need them else. We need your you know two of your developers to go to work on this, your marketing person to go work on that and here's some replacements or they can say oh, it's nice that you've got these plans or even in one case can we double your team size and when I when I pushed back they they saw that as a sign that I didn't believe in the didn't believe in the vision as much.

I wanted to keep going with a smaller team and grow it gradually to not, you know, in some ways you want to keep your team morale and like high, highly effective teams are hard to just double in size overnight and stay highly effective. So I had some strong opinions and it didn't always massively align well with working for other people.

So eventually I realized I'm going to have to, I'm going to have to either learn how to get good at this learn how to manage up better, get better at middle management and politics and all those things, or I'm going to have to do my own thing and do my own thing felt more long term sustainable and enjoyable.

So eventually I ended up doing it in a way that. I was trying to design my ideal job, so I really loved working in small teams. I really found it really fun. It felt like you're working with a group of friends. You could know everybody really well. You could get a lot done. I just experienced getting a huge amount done with a small effective team.

And I like that everyone could have the same goal in a small team. But once you confine yourself to problems that only a small team can solve, you can't go raise money. You can't, it just doesn't doesn't make sense. It's not very investable. So I knew I had to self fund it if I, well, I knew self funding it would be probably more sensible.

And then, so it's kind of working backwards. It's not the normal founder story, but I was looking for ideas, problems, markets where a small team could be really successful over many, many years, hopefully decades. Solving a problem really well and Postgres seemed like an ideal ecosystem for that it had track record.

There were small independent companies that existed for multiple decades, doing great work, contributing back to the community, really valued members of the community. So it felt like a really nice place and also it wasn't controlled by one corporation who could, you know, there wasn't quite the same platform risk you get if you build for a different platform.

So there were so many nice things about it. It really got good vibes off the community, dipped our toe in, started to get to know it, started to explore what tools could be useful. That's what we were good at. We'd built tools in the past. How to make them good. We had opinions anyway, or we thought we did, we thought we knew how to make them good.

So yeah, that was kind of like the why, and then the how was gradually going part time. So going down to four days a week, a very entrepreneur-friendly employer that I worked at called Savanta. They, they're a market research firm and they let me go down to four days a week. And the idea, they always knew that my plan was to go start my own thing.

And they were very supportive of that, which was great. So gradually going down, doing research, talking to people, talking to friends that use Postgres, talking to their friends going online, looking, following IRC, Slack, wherever anybody was asking Postgres questions. I was there looking at what people were asking what kind of problems they had, what tools they were using, what things they liked, what things they didn't like, that kind of thing.

CLAIRE: Very cool. You know, working four days a week is an interesting thing. Now, when you went to four days a week, part time at your company, though, you were still obviously working the other day cause you were trying to incubate and nurture this business idea, this company idea. Is that right?

MICHAEL: Yeah. Great point.

So yes, I sometimes described it to friends as I went down from about five and a half or six days a week to four. And that's because when you work at a startup company you're often working into the evenings or it, especially bear in mind, I cared too much. I would always be doing probably a bit too much.

And that was my general pattern through working with other people. But when I went down to four days a week, I had to, I had to work out, you know, I had to empower my team a little bit more, which is definitely a fault that I hadn't done that as much before, but giving the team frameworks on how to make quick decisions, easy decisions on the day that I'm not there what frameworks can they use to like, what would I do?

What could like, what could they look at? They could give them access to things, get them closer to customers, that kind of thing. It actually made the rest of the time, the rest of the days that I was working there easier as well. So it felt like I went down from working a bit too much to actually I can just work these four days and that that meant I could, instead of trying to start pgMustard evenings and weekends, which I was doing at first I, and also Dave, who I was working with at the time, could both be off on Fridays and do a full day of work on a Friday, just on pgMustard.... we loved those days, which was nice.

CLAIRE: Very cool. The only time in my life when I've worked 4 days a week, which was for, for several years, probably for 5 or 6, at least 5 years was when I had little kids.

And I, when I came back after my first maternity leave, I had to basically interview at Sun for a new job because when you, when you take a six month leave, your previous job is gone, right? So you have to go interview for an equivalent thing. So I got two offers and with both of them, I'm like, look, you can have me four days a week, or you can have someone else five days a week, but I'm only coming back four days a week and they both picked me and so I picked one of those jobs.

And I did that for years and I was fairly religious about it. Like I did not, I was not online on Fridays. I was not checking my messages or any of that. I was from Thursday night to Monday morning, I was a full-time mom. But then during those four days a week, I probably worked 11 hour days or something like that.

It was pretty intense. But I took a cut and pay to make sure like that there was no expectation that I would be available on a Friday. And it was a nice period of my life. We went to the mountains for a long weekend, every weekend.

MICHAEL: That's awesome

CLAIRE: So it was kind of cool. Anyway, I wish I always had four days a week.

It would be a a nice lifestyle, I suppose. Okay, people who don't know the answer to this, and I'm one of them, probably wonder this every time they go to their website. Like, why mustard? Like, why is the name pgMustard? There's got to be a story there.

MICHAEL: Yeah, it is a question I get a fair bit.

Actually, I ended up writing a blog post about it a couple of years ago. And. it was quite fun to tell the story. It's not as fun a story as it sounds like it could be, but because we were exploring ideas in the Postgres space before settling on what the product did, we did kind of need a placeholder name, a domain, like a place we could put website and you know, place people could drop their email addresses if they wanted to speak to us about anything.

So we needed a domain name before we knew what the product did. So partly it needed to not mean anything. I looked around and it was quite nice that in the Postgres space, a lot of tools started with PG and then a word, which meant you could get away with just a single word name.

You could, you know, because single word names are difficult. If you ever want to be found on Google, or if somebody recommends it to somebody else, can you actually find the website? So it needed to have all those kind of basics of, you know, unique, is it easy to say? Is it easy to spell? I'd worked at GoCardless.

I think I mentioned them already, but I also wanted it not to be a negative name. GoCardless didn't do card payments. It did other payments, but it felt always felt negative to me why is it kind of felt aggressive? Why are we telling our customers what to do? So yeah, I wanted something that had positive connotations and we've also the domain we wanted the .com obviously or everyone always does don't they?

So it was available and I liked the words and, and the color, which helped in is it mustard is slang for kind of good or awesome or something. If you say that's mustard, it's kind of, that's awesome. It's not widely used, but we've got a few words like that in English. Like mint is another one.

So considered pgMint and, you know, pgStripes actually owned for a while. That was probably the second. I think I had pgStripes.com and pgStripes.dev or something like that. So yeah, it could have been any of those. I liked the stripes. I liked the idea of faster stripes being a performance tool.

But mustard, we got lucky that one of my, probably my favorite testimonial. Actually, I've got to give a shout out to Piotr Adamiak from Oliphant Consulting. He was one of our earliest customers, and he said "I have to say, I find your mustard hot stuff really user friendly". So it does lend itself to a few puns.

So, which will always make me happy.

CLAIRE: That's really cool. So what did Piotr say again? Say it again, please.

MICHAEL: He said, I have to find your mustard hot stuff. So yes, spicy tips or, you know, that kind of thing.

CLAIRE: I like it. Hot stuff with spicy tips. That's very cool. Okay. So the title of this episode today is My Journey to Explaining Explain.

I think that we try to reach a lot of people in the Postgres world. I obviously know people who are experts and developers and contributors who listen to the podcast. But I think there's also a category of people who are new to Postgres. Maybe they've worked for years in other databases, but not in Postgres.

Or maybe they're, they're just getting started in their careers or as a developer. And so I don't want to assume that our listeners know what EXPLAIN is and what it does. So let's just start there with the basics, maybe explain it....

MICHAEL: Yeah, of course

CLAIRE: Explain it as if you're talking to someone who's, you know, just deciding to study these kinds of things in college.

MICHAEL: Oh, wow. Yeah.

CLAIRE: Early stages.

MICHAEL: I'll give it a go and you can, okay. Pick me up if I'm pitching it wrong. So EXPLAIN is a keyword that you can put before a query that you run against the database. And instead of it, them running the query, it will instead return a plan an execution plan of what the database would do to execute your query.

So, or to return the results or, you know, to do whatever you asked it to do. But it won't do it. It will just tell you here's my plan. That can be really helpful for performance reasons. So, for example, if you start running a query and or if you're scared that a query is going to take an hour, it'll be really long or really slow and you can't handle that.

That's not okay. You can put EXPLAIN in front of a query and just get an idea of what steps is it going to take? Is it, does it think it will be relatively low cost in, you know does it, is it going to use an index? And does it, does that look fairly cheap? So there's certain information you get back.

However, it is. I can almost a-whole-nother language. It's in English, but you get, it's quite a lot of information quite densely packed.

CLAIRE: So when you say it is a whole other language, you're talking about the results that you get.

MICHAEL: Yeah, the output.

CLAIRE: Right in front of you, the output that you get from an explain.

Correct? Yes.

MICHAEL: Exactly. So that can be a little bit daunting. So on simple queries, it can be quite short, but on complex queries, it can be, you know, hundreds of lines of text with a lot of statistics, a lot of numbers in there, not all of which tell you exactly what they are or mean.

So yeah, it can be intimidating and sometimes you'll find in teams that people have kind of different levels of being able to understand them. Some people have, it's quite common to have multiple people on the team that have no idea how to read them. And maybe like one or two that are very good at it. And one that you go to when you have a really gnarly one. And I, I knew that for development teams, having spoken to a bunch of people, but what I didn't realize until a few years into the journey speaking to a Postgres consultant, they said, that's true even at Postgres consultancies.

So there are levels to understanding EXPLAIN and what we noticed, also that's EXPLAIN on its own. It will just give you the execution plan, but won't run the query. There's an important additional parameter so you can run EXPLAIN ANALYZE and that can be written the English, the British way or the American way which is a fun, fun fact and that will....

CLAIRE: Wait, wait, what do you mean the British way and the American way?

Talk to me.

MICHAEL: Ah, so with an S or with a Z.

CLAIRE: Oh, and both work.

MICHAEL: Both work. Yeah.

CLAIRE: I assumed it only works with a Z. I think it should only work with a Z. Sorry, I'm a little biased.

MICHAEL: No, that's okay. It makes me happy that it works with an S and I was very, very happy to present at a London event and use S's everywhere.

CLAIRE: Oh, and Rob Treat in the chat says, I think you mean, I think Michael means to say with an S or with a Zed.

MICHAEL: I made so much effort to say Z.

CLAIRE: Oh, well, that's quite a nice little tidbit. I didn't know that. Good. I'm glad to, today I learned (TIL).

MICHAEL: Yeah.

CLAIRE: EXPLAIN and ANALYSE with an S.

MICHAEL: Yeah, so it does the same thing and I haven't said what it does.

Sorry it will also execute the query and return execution statistics, which importantly it includes time. So how much time was spent on each stage? So that's not super helpful if your query is going to take an hour it's going to take you an hour to get those results but if you really, if you're going to have to run this query a few times, or, you know, quite often it could be extremely helpful and performance work is a lot about understanding why is something slow and looking at the bottlenecks.

So EXPLAIN ANALYZE is what we focused on. And it's almost another tool on top of EXPLAIN, and there are lots of other parameters that are very useful as well, but that's the, that's the key one.

CLAIRE: Well, and I think if we, if we step back and you did a great job "explaining" it, I think that fact that you embrace simplicity in so many things you do comes through in the way you talk.

Right. And so I love. Everything about what you said, what you explained I think if we step back a little bit, though, like, the, the point I would also make to that 20 year old or 18 year old or 16 year old is that SQL the language, right? Not the Microsoft SQL Server database, but the language itself.

Is a declarative language and what that means is it's not like some of the other languages where when you're programming, you're basically telling the computer what to do. Right? In this case, you're saying, this is the result I want, or this is the question I want answered. Correct? And so to that end, you do need something like explain and explain analyze because when you say, this is what I want to query, you don't know what approach the database is going to take or how optimal it will be, or whether you need to revise your query and ask the question in a slightly different way in order to get you to the answer faster.

Does that make sense?

MICHAEL: That is a brilliant way of explaining it. Yes, absolutely. It's the best and the worst thing about SQL, right? It's it handles all of that stuff for us. But it's also opaque unless we look into it. So yes, it has choices and that can be, if it's got an index.

On a column that you're filtering on, it has a choice still to, it has a choice to use that index, or it can still scan the entire table, or it has other scan types that it can choose in certain cases. So, scan types are one choice, join order is another choice there's all sorts of that, they're probably the two best, biggest, but yeah, it has lots and lots of different choices it can make, and it's doing so based on a cost model.

It's so it's estimating the cost of doing each of these, and it's ultimately picking the plan with the lowest cost. So that's what you get back when you run explain on its own, you get just these arbitrary unit costs and it will tell you the cost. It will only return the cheapest plan that it found with its costs.

But to find out what the actual performance is and what you need to run it with ANALYZE and that was always been the same plan as when you run it with EXPLAIN with, with some slight exceptions around how many parallel workers it chooses and things like that. So like some slight execution related differences.

But yeah, it'll always be the same query plan, but now with the actual timings is the obvious one, but also if you include other parameters, like BUFFERS is probably the next most important or definitely the next most important that it will also tell you the amount of data being read, or for example.

CLAIRE: 40 minutes, 40 minutes into the episode, when Michael Christofides of pgMustard first brings up the topic of BUFFERS.

I'm impressed, I'm surprised you lasted that long, because you are well known for your opinions, going back to the fact that you are opinionated, you have opinions about BUFFERS, correct?

MICHAEL: Yes, absolutely. And there's, I haven't met many people in my life that are more opinionated than me, but one of them I need to give a shout out to is Nikolay, and I'm going to give it a crack, Samokhvalov, who's my co-host on Postgres FM.

And I think he might be even more opinionated than me, especially around the topic of buffers. And we've both in the past blogged about the benefits of using buffers because it's not on by default, when you use EXPLAIN ANALYZE, lots of people use EXPLAIN ANALYZE without it. And it can really help people, not just in terms of spotting certain issues that you can't spot with timings alone, but also in understanding why something's slow.

So I think a lot of people that use EXPLAIN ANALYZE, a lot of developers that haven't used it a lot before can, can use it, spot that there's a sequential scan that's filtering out loads of rows, add an index, see that it's much faster and get this feeling that it's magic. Okay. But if the inclusion of BUFFERS will show them that they've gone from reading six gigabytes of data to reading, you know, 24 kilobytes or something like that.

And that suddenly it becomes extremely obvious that it's not magic and it's, it's purely about efficiency of reads. So, yeah, that's why we both feel so strongly about it. And just trying to encourage people bit on a bit of a crusade to encourage people to use it by default, not just individual developers, but also anybody creating training materials or writing blog posts or going on podcasts.

So yeah, just trying to encourage people to spread the word and help people understand how, you know, how database performance works, that it isn't magic and that you can. But by making things more efficient, we can make them a lot, lot faster too.

CLAIRE: So I first met you in person at pgDay Paris earlier this year.

I know we'd interacted online before then, and we follow each other. And I know that you attended the live chat on Discord for previous podcast episodes, which I was so excited about the first time you showed up. I was just thrilled. But we met in person in Paris. And you were there to give a lightning talk and I'm going to drop the link into the chat but your lightning talk, the title was "BUFFERS by default".

So that's how I knew we had to talk about it today because I'd just seen you give that talk. And so in the YouTube video, I just dropped in, I think you're 6th on the list of lightning talks. And it was a 5 minute presentation where you make your case as to why BUFFERS are so useful.

Let's just back up a second. Like what are BUFFERS exactly? What does that mean to turn them on in EXPLAIN? You told me the benefit just now, which is very compelling, but what is it exactly that they are?

MICHAEL: Yes. So you will get extra statistics at each node, so one thing I didn't explain about it.

One thing I didn't explain well, was that. You'll get this plan, but it will be kind of a tree structure. So you have the, the final operation will be the first one you see, and then that will show you any children operations that it's, it spun up to, to execute the query. And that can go, and it's very tree-based often in, you know, each parent having like one or two children, that kind of thing.

And each level of that, so each node or each operation will report how long it took, but with buffers, you also get how much data was read as part of that subtree. So if you get all the way to the leaf nodes of this tree, you will see each scan and how much for example, how much data it read from Postgres shared buffers.

How much data it found that it read that it didn't find in the shared buffers, and it will report that in number of pages or number of blocks. And so you'll get like a, an integer number, maybe like 10,000 and each one of those is by default in Postgres 8 kilobytes, so you know that has read, what, 8 megabytes, 8 megabytes roughly of data, to read 1000 pages.

So, you do have to do these calculations if you're just reading more explain output, but once people know that they can keep an eye out and it's much more intuitive to understand. Well, generally it will correlate really well of what the slow parts of a query are and how many buffers they're having to read or write or whatever else.

CLAIRE: Well, and it's interesting. You're still, you're continuing to focus. Like you just talked about how it's more intuitive to understand that whole focus on simplicity, like just keeps coming out in this conversation. It's whatever that word is, that German word for seeing something over and over again. And I'm seeing that with you.

In simplicity you had an episode of your podcast the other day. I think it was episode 94 if I remember correctly, and it was called the sequel because it wasn't the 1st time you had talked about buffers on your podcast with Nikolay. But there was something you said, one of you said in that episode that I really liked, which is that it's the best way to figure out if you're doing work faster or not doing the work at all.

Did I get that right? Does that resonate? Or do you remember one of you saying that?

MICHAEL: I could believe that we said something like that for sure. I don't remember which one. And I, I do, I do remember a lot of good quotes about performance work along the lines of the fastest way of doing something is not having to do it at all.

And so, so reducing the work, I'm a big fan of like less is more and, and all those things. If we can be very precise in just the data we need, if we can look it up very precisely and not have to read anything else. That's going to be hugely more efficient, not only database, not only server side, which is what we're looking at here, but also in terms of transmitting data over the wire to the client.

So yeah, the less work we can do, the better or, and the kind of the extreme version of that is if we can avoid having to do it at all, then that's a win, right? And it's often one you don't consider depending on where you come in to a problem. If you're the DBA or you're somebody that's been asked to help speed up a query does take step it, it does take you kind of a little bit of lateral thinking to step back and say, do we need to run this at all?

You know what? Why are we running this? Why are we running this? I don't know, 10,000 times an hour or whatever it ends up being by asking those questions. You do sometimes get to a much better global situation than just by optimum, you know, adding an index to make that 10,000 times an hour thing more efficient, faster.

But if you could turn it in, if you don't have to run it at all, your database is going to be happier.

CLAIRE: It's interesting this whole focus on do we need to run it at all? It applies to other parts of life too. Right. So I, after you work in Postgres for a while you start to see, at least I start to see, analogies everywhere.

Like I start to see the whole world as a resource management problem. So I think about even producing this podcast and one of our producers, Ari Padilla and I have conversations about how can we improve the efficiency of our post production workflow after we've done the live recording so that we have to do less work to get from that juncture to the published state.

And anyway, so there's Postgres analogies everywhere.

Okay. So something else that you said that I thought was really interesting and, you know, full disclosure, of course, I work for Microsoft, so my focus is primarily on doing things in the Postgres community, things that are open source focused, community building focused: this podcast, I was on the talk selection team for POSETTE: An Event for Postgres, which is, this is going to be the third year of our virtual conference.

And it's going to happen this year in June 11 through 13. And I think Teresa, the chair, might have dropped the schedule in the chat a few minutes ago. So that's what I do. I am located organizationally right next to the Azure Database for PostgreSQL managed service team.

You know, my boss is responsible for that line of business around Azure Database for PostgreSQL. So you said this, and it really resonated given that, you know, the cloud pays my salary. You said, I do think we're in a new world with cloud providers now, where, for example, pg_stat_statements is off by default in Postgres, but in many cloud providers, it's turned on by default, which means that for many users of Postgres, pg_stat_statements is on by default.

Those words resonated with me. I do think we're in a new world with cloud providers and how people consume Postgres, how they use it, how they run on it, and I wonder if you want to riff off that.

MICHAEL: Yeah I can definitely and I think there's another big thing at play that I didn't mention then.

Which is also how Postgres is being pushed forward. And if you look at the list of committers, and Microsoft's a great example. You employ multiple committers, multiple people, and not just committers, but also other contributors and people that do a lot in the community, sponsor a load of events, but you're not the only ones, thankfully.

And there are a lot of other large cloud providers also contributing, not just committers, but to the community and to events and to the education and to pushing Postgres forwards. And that, that looked very different 10 years ago that it wasn't so much hosting providers, it was much more consulting companies that were, that were shouldering the large burden of that.

And they still do. They still do often consulting companies also now provide managed services, but.... There's this really interesting history of bit like how Postgres has been effectively funded and I don't necessarily just mean financially, but how it's been built, who's actually written the code, who's actually written the docs, who's contributed to this thing that we all use, love and work with.

The cloud providers are now a huge part of that, including Microsoft. So it is a really interesting new world from those two perspectives. Not, yeah, not just who's pushing it forward, who's making it better, but also... What's the experience like of the end user. So often in wherever you are online, if somebody says I'm using Postgres and I've got this problem, they won't say I'm using Postgres on RDS.

I'm using Postgres on Azure. I'm using, you know, they won't tell you where they're using Postgres. They'll just say I'm using Postgres. So they don't in their head, they're not thinking I'm using some slightly modified version of Postgres or some they think they're using Postgres. So people's experience of what Postgres is, is slightly different now than it was well, I was going to say that it was 10 years ago.

Of course that's true, but it's not, you're, you're so much less likely to find somebody with default config or with no backups or with, you know, no HA set up because a lot of these things are now done by default. And my example was pg_stat_statements, but there are all sorts of extensions that a lot of cloud providers are now choosing to turn on by default for people or settings that they're tuning for people, depending on the instance size and things and there's a lot of advantages you have as a cloud provider you know their box size, you know a lot about that customer maybe they've got spending limits in place or they've got certain things that you know about them that Postgres core developers don't know about their customer the whoever's just installed it.

So there's a ton of advantages there and as a community, as people that, you know, if I make a tool I was talking to Nikolay, he does consulting, he helps people out also with tools and we have to then adapt. We have to think what is the general experience and it's not just people running self-hosted Postgres anymore, it is people running flavors of Postgres on all of these cloud providers.

So it is, I think it is slightly different.

CLAIRE: So as you think about your people who come to pgMustard for help with EXPLAIN, you also have to think about people who are running in the cloud, right? And what do they need from pgMustard? Is that fair?

MICHAEL: Yeah. And also what do they have access to?

Like, can they use auto_explain? Until last year, I think, Heroku didn't support, well, Heroku, one of the earlier managed Postgres providers didn't support auto_explain, even though it comes as a contrib module. They do now, it's great most cloud providers do, but not, that wasn't true even as, as recently as a year ago.

People not having access to install extensions is a big difference between managed Postgres and self-hosted Postgres. So it's a little bit kind of what are they likely to have set? What are their defaults? But also it moves the conversation a little bit from what do the core team have to worry about versus what should be handled outside of core.

So one example might be, and it was kind of related to pgMustard, and it is random page cost. So we talked about Postgres having a cost based opt like model for choosing the right, or choosing an optimal query plan. One of the most important factors there is the difference between the cost model for how much a certain read will cost, or how long it will take.

And historically a decent approximation was that a sequential read, so reading a table in order page, like page after page, would cost about four times less than doing a random read, more like an index scan. So reading pages not in order. However, that's not so true nowadays with SSDs. And a better approximation is that instead of it being four times more expensive, it might be in the order of 10 to 20 percent more expensive.

So a lot of people are moving random page costs down to, instead of being four, being more like 1.1 or 1.2. So that can be changed on the Postgres side in core. I probably argue that there's a good argument for it, but it can also be changed by each cloud provider without core having to do anything.

CLAIRE: I looked up before we started today whether pg_stat_statements was in fact turned on by default in Azure Database for PostgreSQL and the answer was it was, which means, and you probably knew that already, that's a really interesting example with random page cost. I love that you're chock full of examples.

MICHAEL: Before I forget to ask though Claire, we talked about everyone's experience with EXPLAIN and that first experience of sometimes it's like a wall of text... and I definitely had that experience and I was a bit surprised when I read, was reading examples online where somebody would paste what on earth, like, how do I make this faster?

And within a few minutes they were getting help from somebody online and, you know, just from reading the EXPLAIN plan, they were able to say. Add this index and it'll be fine. And the person goes, yeah, that worked great. Do you remember the first time you like came across EXPLAIN plans or like first had to try and understand one?

CLAIRE: I think for me, the first time I came across EXPLAIN plans was in blog posts. Because that's one of the first things when I joined Citus thaT people leaned on me for, particularly because we were spread across five or six countries. And, you know, people with English as a second language and you know, engineers who were, well, most of them were brilliant, but they were used to speaking engineer to engineer.

And when you write a blog, you are writing to other developers, but you are, you're writing to a spectrum of potential users, righT, Who might be expert in that particular topic or might not yet be expert in that topic. So your language needs to be really super clear, right? And it needs to be unambiguous, right?

I'm a stickler for not using words like "it" or "this" or "that" because they stop a reader in their tracks to try to figure out: what is "it"? What are you referring to? Which of the three possibilities in the previous sentence might you be referring to? So anyway, the first EXPLAIN plans I ever encountered were in my first couple of months at Citus, and it was in reviewing other people's blog posts.

Where they were putting them as examples in the blog. And so, you know, I had to figure out what's an EXPLAIN plan. Like, what does this do? Why is it formatted like this? How do I make it readable in the blog post itself? Cause you know, the results can be really wide or they can, you know, line wrap funny if you don't code it.

That was my first experience and given how prolific Craig Kerstiens used to be as a blogger. Who knows? It was probably one of his blog posts.

MICHAEL: I used to love, I still love, but you definitely used to blog a lot more on the Citus Blog. And I remember several amazing ones. I think we actually linked to one within our product. There was a one, Citus did a blog post on Faster Counting, it's amazing for anybody that wants to look into count estimation methods and things.

It's a really, really good post.

CLAIRE: I'm going to go dig that up right now and see faster Postgres Counting. That is, was written by Joe Nelson.

MICHAEL: Yeah,

CLAIRE: That blog post was written in 2016 and I can just tell you, I know this without going and looking at the analytics, it's still gets a lot of page views and organic traffic, it's still popular.

MICHAEL: We still link to it. We think it's great. It's exceptional, really well written, really thorough and very helpful.

CLAIRE: Yeah. Joe is an engineer's engineer. And he's also an exceptionally good writer and communicator and actually did a lot of the Citus open source documentation.

So, okay. So I want to pivot a little bit. And ask you about ask you a stylistic question. You know, when we promote this live recording and the podcast itself, then the title of this episode 15 is "My Journey to Explaining Explain", you know, I paused for a second. Like should the "explain" in the last word in that episode title be capitalized?

And what do you think? Should it have been? Because it's not. If you look at the graphic everything is mixed case.

MICHAEL: Yeah. And there is a, I think in chat, somebody linked to the wiki. And I think there's a slightly sarcastic comment saying here's a list of talks and blog posts about EXPLAIN.

And then something like most of which are called "explaining explain". So it's I'm definitely in good company with, in the bad jokes club, so I actually haven't used that title myself or anything before before today. So thank you for [making me] part of that club, but yeah, the capitals thing is kind of an age old debate in SQL query writing, isn't it?

I'm personally not, I'm not dogmatic about this kind of thing. I think if in context, people know exactly what you mean, it doesn't matter and probably skew a little bit towards writing things, lowercase where I can, because it's slightly less "shouty". I'm definitely part of the generation that grew up with a lot of texting and some generational differences on how much we use caps lock for everything.

CLAIRE: So to you, ALL CAPS can mean shouting and yelling and being angry. Is that what you're saying?

MICHAEL: Exactly. So but I do use EXPLAIN with capitals in a lot of things I do as well when the context is important. So for example, if it's something you're hoping Google will show, writing it in capitals helps people that are searching for that understand you are talking about the SQL keyword, not the English word, for example.

CLAIRE: Right. That's right. In blog posts. I actually tend to like to capitalize it when I'm talking about the SQL keyword, because I find that it makes it pop a bit more in a good way. If you're looking for examples if it just makes it clear that it's not just the regular English word that we're going to start talking SQL now.

So I like the way it looks there.

MICHAEL: Do you mean like in a within a paragraph? I completely agree, but then when we include like code snippets, I don't mind so much. But yeah, yeah, exactly. I said I was opinionated. Maybe I'm not so much about this one.

CLAIRE: Well, here's something you are opinionated about.

When you do. When I go to the Postgres documentation I typically don't go there by like going to a bookmarked URL and then browsing my way to the relevant page. I'm a search person. I just go into the search box in my browser. And I type in a few keywords and I'd like to think I'm really good at search because I generally will get what I want in the one of the first few search results, click on it, and I'm there.

But sometimes if I'm looking for a Postgres docs page can end up being an older version of the doc, not the latest one, maybe a two year old version or something like that.

MICHAEL: Yeah

CLAIRE: And I like the fact that there's like a little message at the top that says in like a yellow box or something. Maybe it's not yellow, whatever color it is, a colored box.

And it says, you know, you were looking at an older version of this docs page, would you like to go to the newest version? And then I can easily click to get current, to get to modern day. But we started somehow talking about this area and you had some strong opinions about things that could have, would have, should have been done.

So that Google wouldn't serve me up an older version of the docs page. Am I remembering that right?

MICHAEL: Yeah, you're spot on. So this used to wind me up so much. Like back in 2018, 2019, when I was doing research around Postgres learning about it, and I'm definitely in the group of people that when they're trying to learn something, my search engine history is hundreds of pages long of, you know, what I've actually searched yeah, so I would turn to search engines as pretty much my first port of call when I'm learning and over and over again, I would search some, I'd look something up in Postgres and then only halfway down reading the documentation, realize I'm reading an old page.

So, yeah, you're quite right. If the version is out of support, you will get a yellow text box warning you at the top of the page. But if you happen to land on one of the versions, maybe three, four years out of date. So nowadays that would be what like version 13, version 12, it's still in support, but it's not like it's, it's also still three or four years old.

And things can change in that time, like things can go from being not true to true or defaults can change. And it could be quite frustrating to have read all of that entire page without them realizing. So I'm pretty sure it happened to me quite a lot and I didn't realize, but it also happened to me a lot and I did realize.

And there wasn't like, there wasn't a great solution. I kept forgetting to include the latest version number in the search terms I was searching. So it would happen to me over and over again. And I eventually, well, I looked into it. I looked into what the problem was and sadly it's kind of it had come up as a topic multiple times on the mailing list, and there were some quite, people thought they were quite risky ways of addressing the problem.

And it had kind of gone round and round in circles a few times, sadly. Lots of people were looking out for good interests and not, you know, bad interests. Really good motives not wanting to tank our brilliant, whatever you want to call it, SEO juice. For whatever reason all the search engines ranking postgresql.org at the top of the results when you search for pretty much anything Postgres related so it had done a great job over the years.

The problem was having multiple pages that were pretty much almost duplicates of each other. Google had to kind of fight spammers that would also do things like that.

And they had to work out which is the real version of this, or what's the most authoritative version of this, what's the best version of this, or the original. So it has loads of different ways of doing that, but one way it does is it has a thing called you can tell Google that this is the canonical version of this page on this site, and it's a risky thing to do, but it has loads of benefits as well.

And yeah, it had been discussed, but it hadn't been done. I eventually gave up hope that it was going to be fixed because it had come up so many times and ended up making a browser extension just for myself and I open sourced it and let other people use it and in fact I think that's one of the first ways me and Nikolay ended up speaking because he was a user of that extension.

I might be misremembering that, but he definitely used it. So yeah, I made that little extension for myself and kind of forgot about the problem. I was kind of gave, but I'd given up hope and I now had a solution. Whenever I clicked on a Stack Overflow link or Google search link or something that went to an old version, it would automatically redirect me to the latest version.

And crucially, it had like some safety measures like it wouldn't redirect if there wasn't a new version of that page and it wouldn't redirect when you're on the postgres docs as well so if I did deliberately want to go to an old version that was like the problem with that's why I couldn't just use a generic redirection tool so yeah, there's probably no need to do that to use that extension anymore though I I still have it installed just because of some Stack Overflow posts but luckily a few years ago in fact, a famous Microsoft employee, person of the year perhaps, Andres Freund, brought this up.

This was back in 2021, brought up the problem again, and it went through a similar kind of, it was definitely like a lot of people that wanted to help solve it. Jonathan Katz included a lot of people that it was Jonathan that ended up making the change. But a lot of people chimed in, helped out.

And it looked like it kind of petered out again. So I was one of the people that chimed in and said, be awesome. We've made this work. I'd learned a little bit about how Google in particular did such engine result placement. So it could link to a couple of things that might help people have a bit less fear on what the effect would be.

And Jonathan made the change, they monitored it, so these days if you search for most things Postgres related, so like, you know, syntax type things or information about a certain Postgres feature, chances are you're going to get linked to the version of the docs that have current in them, C U R R E N T, like the latest version of the docs.

So that's, that makes me really happy. I do still every now and again spot one that isn't but we're getting there. It's almost all now. Which is nice.

CLAIRE: So did you uninstall your browser extension?

MICHAEL: Not yet. So the one remaining issue is some old Stack Overflow posts linked to old versions. And I do every now and again, like somebody reported one recently.

I can't remember which one. It was something like GiST versus GIN indexes. So if you search for that, some search engines will rank some really old version of the docs, maybe like 9.1 or something.

CLAIRE: Okay.

MICHAEL: And I think it's because there's a Stack Overflow post that has got a lot of views. Clearly people are interested in the differences between GIN and GiST indexes.

And that is then seen as by Google as a very good source of information about this. So they rank, even though the Postgres docs tell Google and other search engines that the canonical version is the current version, they're like actually we think this one's better. So I've submitted a little edit for that.

I don't think it's, I don't know if it's been accepted yet. I haven't checked, but so I'm trying to go back and edit the old pages and the old questions and answers in Stack Overflow to gradually improve it as well.

CLAIRE: So for those of you listening online, we'll have a link to Michael's browser plugin, pg_docs_bot the browser extension in the show notes.

MICHAEL: Yeah, sure. Let me know if you use it. I it's a bit overdue an update, but it works.

CLAIRE: Yeah, and I stand corrected in my example. In the kickoff of this thread of the conversation, I talked about how you would get that yellow box if you were on an older version of Postgres docs, but you're right.

You're exactly correct. I was wrong. It's only when you're on an unsupported releases docs page that you get that yellow box. And then if I happen to be just one release back, but I'm looking for the current, it's very easy to be in the wrong place and not realize it. So I'm really glad that this change got made.

What release was it that it was made in that the change you said Jonathan Katz ended up

MICHAEL: Well, it's the website. So it doesn't need to be like, it's not, it's not coordinated with releases, but I think it was in March. I've got my notes here in March, 2022. Okay, two years later, we grad two, I mean, it made a really, it made a much faster impact than many people were expecting, like, within a few weeks, it was much much better.

But over the next few months, and still now I'm noticing some more pages flipping, which is nice.

CLAIRE: Well, one of the things I really like in the Postgres world is that there is a big commitment to the documentation. I mean, I guess that's true.

A lot of open source developer communities, right? Docs are important.

And it would be nice if, you know, everything was so intuitive, you didn't need documentation, but that's not the reality of really complex system software yet. At least, I don't think it is anywhere. So, docs matter.

MICHAEL: Yeah, for sure. Well, it depends. I think there's like a certain amount of I do believe the same thing.

I think a lot of user interfaces can be made so that they are self explanatory. So you can use them. The information you need is available to you at the time that you need them. And you don't need to look things up platforms, things that you need to develop for, or interfaces that aren't graphical. I do think you need documentation.

You need to have definite what is something, what could, what's the maximum something can be, what's the default. When you don't specify it so many things have to be documented and have to be accurate. I think accuracy in docs is, is underrated. I think we perhaps take that somewhat for granted with the Postgres docs because it's normally written.

The documentation is normally written by the person who wrote the feature. In fact, patches of like, I see quite a few patch discussions where somebody's wondering why nobody's got back to them on a patch or when nobody's reviewed something, it hasn't been committed. Something some people bring up is what this doesn't even update the documentation yet.

So it definitely can't be committed so that it's really nice to see that level of commitment that it's not just an addition to the product is part of the product. So, yeah, I've got huge respect for them. And they're often cited as very, very good. They could definitely be more comprehensive in places.

They're much more referenced than guide style. They contain examples, but not loads of examples. Like there's so many ways to make them better. And definitely an opportunity for people that are getting involved. Like it's something I did. We, there's a great page on using EXPLAIN in the Postgres docs, but it's one page.

And there's only like a few examples in it. You can get really deep on how to use EXPLAIN. And so it's very much only an introduction. It covers the, it covers the big, like the beginning things you need to know very well, very clearly. But yeah, I've made a glossary of terms of all the things that I really wanted to know when I was building the tool, but also doing performance work generally.

There's so many things that you have to look up and that there wasn't, there weren't good reference materials for. So it's something that I've been, it's a bit of a maintenance nightmare as new versions come out, but it is, I agree with you completely, good documentation is worth so much and it's so helpful exactly when you need it.

CLAIRE: So before we wrap up today, I'm curious if you want to give a shout out to any of our listeners to some of your favorite Postgres resources for learning. You already talked earlier about how your 1st port of call when you're doing learning is, you know, a search engine and that you're searching for things that have been published on the internet or already exist out there.

But I'm curious, are there any conferences, any websites, any books, anything in particular you want to point people to as a great way to learn more about Postgres? Oh, podcasts. Besides this podcast, of course.

MICHAEL: Well, yeah, I mean, it depends. Yeah, people learn in different ways, don't they? I think that's, it's really fascinating.

Conference wise should give a shout out to Citus Con coming up.

CLAIRE: Now called POSETTE. POSETTE.

MICHAEL: So sorry.

CLAIRE: Do you know what POSETTE stands for?

MICHAEL: I'm going to say, I I've read it. I've read your blog post, but I don't remember. Sorry.

CLAIRE: That's totally okay. I mean, it's kind of inspired by FOSDEM. Most people only, only know what the first few letters stand for. And then they kind of trail off and mumble mumble for the last few letters. So it's an acronym that has become a name. You know what I mean? And so that's the vision for POSETTE: An Event for Postgres too. I'll just tell you what stands for "Postgres Open Source Ecosystem Talks Training and Education".

So, but no one is expected to remember that ever. So, okay. So there's your shout out for POSETTE, which I was not fishing for, but I thank you for it. Cause I'm very excited about it.

MICHAEL: I've just realized you have to spell it ALL CAPS then, don't you?

CLAIRE: Yes, yes, we do.

MICHAEL: So maybe you have to shout it when you say it.

CLAIRE: Well, when we use the hashtag online, it's #PosetteConf, all one word, and we do the CamelCase or the PascalCase thing for that, for accessibility reasons, right? To make it easier for people to read. Because when it's all lowercase, you know, things get hard read.

MICHAEL: Yeah.

CLAIRE: Anyway

MICHAEL: Sorry, I'm, I'm conscious of, of time.

I'm gonna give you a few resources that sorry, I didn't answer that properly.

CLAIRE: It's okay.

MICHAEL: There specifically on, on learning, explain. I found a video by Josh Berkus exceptional called EXPLAIN Explained unsurprisingly. But so much so that I've never tried to give a similar talk. I've only ever tried to give talks that are the beginning of like the bit before that, or the bit after kind of like explain beyond the basics.

I think that talk is, is so good and point people to it all the time. Additionally, there's an old blog post by Thoughtbot about reading EXPLAIN ANALYZE. I think it's exceptional. Depesz, who makes arguably the original tool for reading EXPLAIN ANALYZE output and an excellent tool explained.

Depesz has also a series on explaining the unexplainable. That's really good. Dalibo have a great tool as well for reading EXPLAIN plans, those two are open source and great community members like fellow sponsors at the Dalibo was fellow sponsors at the recent event we met at, weren't they? So, yeah.

CLAIRE: Yes. Yes.

MICHAEL: So in addition to those, I really like Planet Postgres. It's a great blog aggregation community initiative.

CLAIRE: I love Planet Postgres. And for any of you listening who blog about Postgres you can register your blog. It's not just anybody who publishes on your blog. Every registration is a combination of the blog and the author, right?

So each individual author on a particular blog has to register, but you can register and then effectively whenever you publish a blog, it'll get picked up and syndicated by Planet Postgres. So it gets tweeted out. To a lot of followers and there's an RSS feed for Planet Postgres as well. And you know, there's policies, right?

It can't be just an advertisement for some commercial technology. It's got to have a big open source focus. But really great way to just keep track of all the people publishing a lot of different Postgres things from all over the place.

MICHAEL: Yeah, absolutely. And in addition to those things that it won't pick up are things like Postgres Weekly, which is an excellent newsletter.

CLAIRE: Peter Cooper is a favorite. He's wonderful. Okay.

MICHAEL: Yeah, they do an excellent job of aggregating the weekly Postgres-related news. One of the highest compliments I ever got about our pgMustard newsletter was that basically we're the second, they considered us the second best newsletter after Postgres Weekly, which I was chuffed about.

And In addition to that something else that won't get picked up by Planet Postgres is Lukas Fittl, whose previous guest of this show, does an excellent YouTube series on "5 minutes of Postgres". So taking, often something that was covered by Planet Progress, but going into a bit more detail or tying three or four things together and explaining it really well and in quite deep, well, considering it's five minutes in quite a lot of depth does a great job.

CLAIRE: Yeah, and, and he does this weekly or even more frequently than that.

MICHAEL: Yeah, I think I'm pretty sure it's weekly. Yeah,

CLAIRE: I'm looking right now and I can drop the link in his most recent episode. He's done 112 of these so far. So he's done more 5 minutes of Postgres than you have your Postgres FM episodes.

I'm just saying. He puts the bio pics on the cover slide or the YouTube thumbnail for the people whose work he's talking about, right? Whose work he is dissecting in a particular episode. And so I'm looking at the friendly faces of Thomas Munro and Melanie Plageman and Bilal Yavuz and Andres Freund.

So it's all about Streaming I/O, which is a new, big, exciting thing that's going to be coming out in Postgres 17, we think.

MICHAEL: Yes,

CLAIRE: And I say, "we think", I can't imagine why or how it could ever be backed out, but Postgres 17 is kind of in the end game of its development, right? So the code freeze happened.

And then we're going to, you know, obviously end up with beta releases that come out over the summer and then it will GA in the fall. Yeah, exactly.

MICHAEL: If like a showstopper bug is found that can't be fixed easily or that has other ramifications, sure, like things could still get reverted. But there have already been a few reverts, so I think things that are still in at this point are a little bit safer.

CLAIRE: Okay. Any other pointers for people new to Postgres? Or want to learn more? I mean, You've given a lot, so...

MICHAEL: I could keep talking forever on this stuff. It's like the stuff I love. But yeah, we, podcast wise, we'd love to have you on ours, but also there are like, I listen to every Postgres podcast.

So if anybody wants to start a new one, you can count me as a new listener. "Scaling Postgres" has been going way longer than like a few hundred episodes. It also does a roundup of the news if you prefer an audio version of that. And yeah, there's more as well, but yeah, I really like podcasts as a medium for learn.

So thank you for doing this. I've learned a lot from these episodes and you've had some wonderful guests on really appreciate it.

CLAIRE: Well, thank you. I, I feel honored that you're here and that we have had such wonderful guests as well on the other episodes. And I think I'm. I think we have guests scheduled for the next four months so far, four or five months.

So like we're starting to book up, it's really kind of exciting. And ours is of course only monthly. So to be at episode 15 is also kind of exciting. I am so glad that we sat on the stairs for an hour and a half and caught up in Paris and agreed to do this episode together. I want to thank you, Michael Christofides for joining us.

MICHAEL: Thank you so much, Claire.

CLAIRE: The next episode of the Path To Citus Con podcast will be recorded live on June 19th at 10am PDT now, you might say, wait a minute, June 19th. That's not the 1st or 2nd Wednesday in the month. What's going on? But in June, the POSETTE: An Event for Postgres virtual conference is happening.

So our team will be a little bit distracted those 1st, couple of weeks of June. So, so we're pushing out and our guests will be Teresa Giacomini and Aaron Wislang, and they're going to be talking about, "Dishing on POSETTE and Postgres" is what I have as the title. But somebody else is trying to negotiate with me to change it to "The Making of POSETTE: An Event for Postgres". Which title do you like better, Michael?

MICHAEL: Say them both again,

CLAIRE: "Dishing on POSETTE and Postgres" or "The Making of POSETTE: An Event for Postgres".

MICHAEL: Nikolay and I argue about titles all the time. I always err on the side of say what it does like, which is more the latter, right? Yeah. But then dishing it sounds a little bit more gossipy and a little mad.

CLAIRE: Maybe a bit more fun.

MICHAEL: Yeah, so Nikolay's more fun. I'm more "say it as it is".

CLAIRE: Okay. Well, mark your calendar if you're interested in joining that one so that you don't get double booked. The short URL to mark your calendar is aka.ms/PathToCitusCon-Ep16-cal. And you can get to past episodes and get links to all of the podcast platforms you can subscribe to at aka.ms/PathToCitusCon, all one word.

And transcripts are included on the episode pages for all past episodes on transistor too. Now before we leave. If any of you have enjoyed this podcast, please rate and review us on your favorite podcast platform. It helps other people find the new show. And you can also post a public compliment on your favorite social media platform.

If you do the social media thing on Twitter, Mastodon, LinkedIn, et cetera. And a big thank you to everybody who joined them recording live here on Discord. And we really appreciate your presence and your questions and all your participation in the live text chat. Thank you, Michael.

MICHAEL: Thank you, Claire. Thanks everyone. Take care.

CLAIRE: Ciao. Ciao.