Talking Postgres with Claire Giordano

CLAIRE: 00:00:05
Welcome to Talking Postgres, a monthly podcast for developers who love this database. I'm your host, Claire Giordano, and in this podcast, we explore the human side of Postgres, databases, and open source, which means why do people who work with Postgres do what they do, and how did they get there? I want to say thank you to the team at Microsoft for sponsoring this community conversation. Today's guest is Boriss Mejías. Boriss is a holistic system software engineer, and that word holistic is kind of important. We'll come back to it. And he's a global solution architect at EDB. He has worked in the database space since at least 2010, if not earlier. If you count his years working on his PhD in computer science, then even more than 15 years. Boriss is originally from Chile and now lives in Belgium. He's fluent in at least three languages, but maybe more. He's an extraordinary, and this is not an exaggeration, this is not hyperbole, he's an extraordinarily talented speaker and explainer of Postgres concepts and best practices. And I first met him in 2019 at PGConf.EU in Lisbon. He was volunteering for the Postgres conference organizers as a room host. And I was giving my very first Postgres talk. And I was so lucky that Boriss was there to kind of support me through that whole process. So welcome.

BORISS: 00:01:34
Thank you very much. Nice introduction. I love it. And I'm super happy to be here. As you read in the social media, I put that I'm a big fan of your podcast. I have my sticker on the laptop. So big fan for real. This is not just words. So I'm very excited because you're a very good host, as we can hear from the introduction. So thank you very much.

CLAIRE: 00:01:55
Yeah I think you're you're a little bit selective, you don't just put any sticker on your laptop so I'm taking that as quite the compliment.

BORISS: 00:02:04
Absolutely, yeah.

CLAIRE: 00:02:06
Yeah now what we need to have happen is for people to be sitting next to you on an airplane and to see that sticker and to be like oh what's Talking Postgres and then you know it'll help spread the word even further.

BORISS: 00:02:18
Oh that happened already, not in a in an airplane but in a train. I think it was when I was going to PGDay Lowlands the last time that happened so people were looking at my stickers and they were oh so you're into Postgres I said oh they recognize yeah and then I also mentioned the podcast, so yeah, there you go.

CLAIRE: 00:02:37
Very cool, okay well it's time to talk about today's topic which is a very long topic title. I don't know how I'm going to fit it in the published podcast episode name but the title is The Fundamental Interconnectedness of All Things. [Yes.] Now, this is not, first for, for people listening, this is not your first time on this podcast. You joined along with Álvaro Herrera on episode three. So in the very beginning, before it was really even a podcast, we didn't know if this experiment was going to go more than, well, actually the original commitment was just for two episodes. And then with you and Álvaro, we thought, well, let's try episode three. And then with Thomas and Melanie, we thought, let's try episode four. And then it just kind of snowballed from there. But the topic in that episode was why give talks at Postgres conferences. So we'll drop a link in the show notes for anybody who wants to listen to you and Álvaro together talking about something altogether different. Sound good?

BORISS: 00:03:41
Yeah, that was fun. I remember that the first two episodes were actually before getting to the POSETTE conference. It was called CitusCon at the time, I think. And our chat that we had with Álvaro was post-conference. So that was also nice to have that, yeah.

CLAIRE: 00:03:59
Yeah because in the beginning this wasn't a podcast this was a pre-event, if you will, to shine a light on some of the speakers who were going to be at that virtual CitusCon thing. But then it snowballed. It turned out in a way that I could never have predicted. And it's one of the favorite things that I get to do. So let's dive in and stop talking about the talk. You wanted to talk about the writings of Douglas Adams. And he's, of course, the author of [The] Hitchhiker's Guide to the Galaxy, right? But we're not going to talk about [The] Hitchhiker's Guide to the Galaxy. You want to talk about a also famous but slightly less known book, which is titled Dirk Gently's Holistic Detective Agency. Is that right?

BORISS: 00:04:44
Yeah, but we're not going to really talk about the entire book, but it's kind of the source for, I would say, methodology that I use and other people use in order to solve problems and how to apply that into many other different things, like how to prepare a talk, how to get the community a better place for everybody, so how everything actually is interconnected. So that's the source of the idea of the fundamental interconnectedness of all things. So let me explain you where this comes from. So in Brussels, I was applying for a job, I think around 2012, 2013, and I had to do an assessment with a psychologist and everything. And then there was an exercise that they will call me on the phone. I mean, a real phone, a physical phone. I need to pick it up. And they gave me already an assignment and I need to go through the process. And they gave me a piece of paper and I needed to take notes. And then at the end of the interview, they asked me for the paper and I said, oh no, why didn't they tell me before that I needed to give this? I mean, I thought was just my personal draft. It's full of scratches and I think this was part of the evaluation. So when I got the evaluation, I mean, it was a positive one in general. I have a very good evaluation in general, except for methodology. So they say that was the thing that I needed to improve. If I remember correctly, it says something like, the brain of Mr. Mejías is very chaotic and unstructured. But however, however, he is able to solve very complex problems and has a very good eye for details Therefore we recommend for him to improve his methodology and the process for getting to a solution, so basically to reduce the chaotic part and then more or less at the same time I was reading this book from Dirk Gently. Not the first one actually I was reading first the second one then I read the first one then the third one there you go with the chaotic mind. And this is the The Long Dark Tea-Time of the Soul. I didn't have a clue about what the book was about, and then I started enjoying it. And Dirk Gently, when he presented himself to somebody, because they asked for the term holistic detective, he said, and I have the book here, so I'm going to quote verbatim, it says, "I'm not, as other private detectives, my methods are holistic and, in a very proper sense of the word, chaotic. I operate by investigating the fundamental interconnectedness of all things." So when I read that, I was like, wow, yeah, it matches my brain, apparently. It says, my methods are holistic and, in a very proper sense of the word, chaotic.

CLAIRE: 00:07:27
Can you read that again?

BORISS: 00:07:35
"I operate by investigating the fundamental interconnectedness of all things." So that triggered my mind, of course, because I needed to find a method for my chaotic brain. And I read the book and then I read the second one. And actually, this holistic term, it feels like it is just a scam so that he can justify expenses like going to, I don't know, [Bahamas.] the Bahamas. But actually, because it's somehow related by many, many paths to the investigation that he's doing. But then in the end, you really see that he's solving the problem by looking at how things are connected. And then he finds things that are not visible in the beginning. But then by going several layers further about the connection between things, he managed to solve the problems or some of them. And that's how I started to investigate what has mean the term holistic, because it has a very bad reputation in some cases, because some people really misuse it in the way that Dirk Gently was misusing it for the expenses. But I think that what is interesting is that it is proposed as a way of looking at things from kind of from above, from really like a global picture, as opposed to the reductionism. Reductionism is when you have a problem which is complex and then you say, I need to split this into its part so that I can understand each part of them. And by understanding the parts of it, so you reduct your system into a smaller part, then you understand the whole thing. Now, the holistic approach, I don't think that is opposite to that. I think it is complementary because it says that the system is larger than the sum of the parts. And I totally believe that because it's not just the part, it's the connection between the parts that builds up the system. So if you just look at the parts individually, you're missing the whole thing, the whole picture. So what I usually try to do when I see some complex problem is that I definitely start by reductionism. But as quickly as I can, I try to go back and then take this holistic view of the whole thing. And it has been useful so far. So I like that. And that's why I wanted to talk about this thing, because I think it could help other people to look at things in a different way and try to find solutions to problems in a different way. That's the source of the whole idea for this.

CLAIRE: 00:10:08
So can you give me an example of a Postgres problem or something that you've had to approach. You're a solution architect. [Yes. Yes.] You probably have had other roles over the years as well working with Postgres and EDB, but maybe not. Maybe have you been a solution architect or a solution architect manager leader the entire time? [No, no, no.] Lots of jobs.

BORISS: 00:10:28
No, I don't know. Yeah, well, first I started, so that's why the term holistic system software engineer, because I've done development, I've done support, I've done sysadmin, and then consulting work, and then from consulting I became a solutions architect, and then global solution architect, so it's kind of like way in that direction. So first development, then going very deep down the operating system, and then going back again to the architecture. So it kind of matches the reductionism and then going back again to the holistic view. So an example in the Postgres world. Very recently, I mean, in New York, we were in the conference. There was this presentation, I forgot his name, about OpenAI. And he was talking about some issue that he... [Oh, Bohan Zhang, I think. Okay.] Yes, exactly, him. Yeah, thank you very much. So he was talking about some issues that they have with very high workload that impacted the query performance. And by the way, it also has some issues with high replication latency. So when he presented the problem, people started asking questions that were really, really, really specific about the query performance. They were asking about logs, for instance, because when you have high workload, you will look at the contention and concurrency and all the logs that can be taken. Also, he said, no, no, no, that was not the problem. And then, oh, did you look at the I/O and many, many different things that could affect just the query performance. And this is, I think, that's something that we usually do, that we try to focus and narrow the problem as it is presented instead of looking at, and then we go again, the fundamental interconnectedness of all things because there are many, many things that can impact this. So while I was listening to all the questions, I was kind of, my focus was on the replication latency because there are some things that can affect that and can be many, many things. And one of them is that if you have vacuum, autovacuum in this case, running on a very large table, at the same time, you're going to generate a lot of WAL files that had nothing to do with your connections from the clients. the application doesn't impact that WAL. And that WAL is coming really, really from the vacuum process.

CLAIRE: 00:12:51
You know when we agreed to talk about this topic I didn't realize that you were going to connect this worldview to your Postgres work as directly I thought that it was going to be more about just how you take inspiration from life, if you will, or just your philosophy toward life more broadly than specifically how you approach your work. So I don't know, you're kind of surprising me. I like this. I think it applies to your perspective on life too. [Yes.] example, I think that you are really a talented speaker. You're very good at getting up on stage and teaching things in a way that sticks. And it's interesting. I think part of why what you teach sticks is because you find ways to weave the technology, weave the lessons, the features, the capabilities, the very specific technical things that people need to know. You weave them into stories or you connect them to other life experiences. So they're more likely to be retained, if that makes sense. And I have a few specific examples of where I think this was true. So the talk you gave last year at PG Conf.EU 2024, which was in Athens, you know, PGConf.EU for those who've never been before is probably the largest in-person Postgres conference, of each year. And each year is in a different European city. So it moves around. This year, it's going to be happening in a couple of weeks in Riga, in Latvia. Last year, it was Athens, Greece. And your talk was titled, Sparta's Dual Kingship and Postgres Active-Active. So I have other examples too, but maybe let's dive into that one a little bit. Like, Does this fundamental interconnectedness of all things, methodology, or philosophy apply to that talk? And was there a connection there?

BORISS: 00:15:01
When I was writing my thesis, and I was doing at the time a parallel with the colonies of Spain and America. So if you look at the Aztecs and the Mayans and the Incas, they did have an emperor, kind of an emperor. So they had a head of the whole empire. So when the Spanish came, they took the head of the empire, and by that, they immediately conquered the whole empire. So the Aztecs and the Incas, they fell kind of quite fast because they took the emperor, and when the emperor is in jail or dead, they have no leadership. So this is very much related to any system that has one master node, that if that node crashes and you don't have a way of recovering from that, then your system is completely down. So in peer-to-peer system, what happened is that you don't have a master note. And then when the Spanish people arrived in Chile and Argentina in the South, the Mapuche people, they were organized in small groups, but they didn't have a single leader. So whenever the Spanish people would conquer one of the group and say, OK, we conquered the Mapuche people. The others were saying, no, you just conquered that group. I mean, we don't follow that leader. I mean, that's just one of them. So it really matches how peer-to-peer systems work, because if you crash one node, you still have all the rest of the nodes that can continue doing sharding or whatever is needed for the system. So I already had these kind of ideas of doing matches between how you organize your nodes, because your nodes in a database are in a hierarchy. You have the primary node and the secondary nodes or master node and the other nodes. And then thinking in terms of that, when I was going to present about Active-Active, I also started to search for government systems in Greece that would kind of match this kind of stuff. And then I realized that the Spartans were having these two kings, which actually matches two active nodes. But not only that, the analogy went even further because these two kings were not just absolute rulers, they needed to respect the law that is being written by the Gerousia, which is kind of the Senate, the democratic group, which is exactly what you need when you need to do an active-active system, when you have a consensus algorithm that decides who is taking the logs for modifying their database schemas and stuff like that. So it matches really, really well. And then by having this analogy with a government system that worked for many, many years and then applying some of those ideas into Active-Active, which is we are building them now in Postgres, makes sense. So as you were saying in the beginning, the idea for me, one of my goals is to make complex ideas in IT or whatever, explain in a way that is accessible to hopefully everybody and that you can remember them and then you can apply them whenever you need to think about, ah, yes, we don't need just only two active nodes. We also need a consensus algorithm, which is like the Gerusia in the time of Sparta. So that's the idea, to make those connections in the brain with ideas that are easier to understand, and then you can connect them to complex systems like Active-Active in PostgreSQL. That was a long answer for a simple question, but there you go. It's the fundamental interconnectedness of all things.

CLAIRE: 00:18:32
I like it. I mean, you do use analogies a lot in your talks, now that I think about it. And by the way, I do too. [Yes.] And it's a dinner table conversation in our house sometimes. My husband will sometimes say that analogy is the weakest form of argument. But I guess I use analogies not when I'm arguing, or maybe I do use them when I'm arguing. Not that I should be arguing. Anyway, I use analogies to help people understand something, to take a complex idea or a new idea for them and put it into a mental model that they might already have in their heads. That's the reason I do it. So in my talks, there's a lot of visuals, but I'm always trying to connect some concept to something they might already be familiar with.

BORISS: 00:19:27
No, I agree. I mean, that works pretty well in the sense that people relate to things that are more connected to our daily life, for instance. And then it's familiarity what we are searching with this analogy. You create a familiarity with something that is known, and then through that familiarity, you connect the complex idea that you want to explain so that people can get into that. Sometimes they don't work, of course, but I mean, sometimes you realize that, okay, this analogy is kind of breaking too easily, so let's pick up another one. But I mean, that's part of the process. I mean, yeah, it doesn't have to be perfect. Oh, I do have some topics about perfectionism, but maybe we can talk about that later.

CLAIRE: 00:20:10
Okay, so last week, you and I were both at PGConf NYC, which is probably the biggest Postgres in-person conference in the United States, or certainly one of the most popular ones. And it was in Midtown Manhattan. And there's probably some interesting things relating to the fundamental interconnectedness of all things that we should talk about. But basically, as soon as I left, I went and visited my parents on the East Coast for a couple of days. And then I started reading the book, the Dirk Gently book, about the Holistic Detective Agency. And I'm very sad to report, I don't even know what page number I'm on because I now use a Kindle to read books. So, but on my Kindle, I am 50% of the way through. So I don't know the ending. And I feel like I just, it is the most unusual book I've ever read in my life. It is so wackadoodle, but in a good way. And it's so surprising. And I feel like every corner I go around, I'm like, what? What? Huh? It's just, there's all these unusual things. I don't want to give anything away. So I'm speaking in vague terms. But I'm just dying to know what the ending will be. And I probably won't be able to finish it until this weekend because I have a crazy busy week at work this week. But I'm really, really curious. So how do we talk about Dirk Gently's Holistic Detective Agency without giving it all away to the audience? Because if they haven't read it yet, I want them to have that same sense of surprise and discovery that I've been having. Maybe.

BORISS: 00:22:02
Yeah, that's interesting. So I would say that the second book, and I was lucky to read the second one first, is simpler to read than the first one. The first one is really, really complex, I would say. But it all makes sense at the end, which is a good thing, because it doesn't let things open in the sense like, oh, okay, he never solved this problem that he just presented just to confuse everybody. No, in the end, everything makes absolute sense. What I would say is that the ability that Dirk Gently has, despite the fact that he is a little bit, how do you say it, nonchalant or everything, is that he has his eye open for anything that could be connected to the case that he's investigating. And he managed to find things where other people would just ignore because they're not directly connected with what is going on. And I think that that's probably the, if we want to take a lesson learned from that, is that thing about keeping an eye open for everything that could indirectly be related to whatever you're trying to solve. And for instance, let me get back to this idea of the WAL because we did a nice presentation with Derk, it's not Dirk, but Derk van Veen,

CLAIRE: 00:23:17
Who works at Adyen, right?

BORISS: 00:23:19
Who works at Adyen, yes, [Okay.] about a case that happened. We presented this in FOSDEM PGDay, I think it was two years ago. And then they had an issue with synchronous replication, where the synchronous replication was taking too long because of the replication lag. And then again, the reason was because of a vacuum of very large tables will impact the size of the WAL files. So that's why, also based on experience, because of that experience that I had, I had my eyes open in a different place when I was looking at this presentation in New York City last week. but then it doesn't stop there because there is another thing that is related to the issue that is not when you whenever you read a documentation or a book or a blog article you will never see these two things connected. It is when you generate WAL files Postgres is going to do two things. First of all, if it has a file that is an old WAL file it's going to reuse it because you want to use the same blocks that are physically on disk because they're already tied together so don't split files and stuff like that on the system so it's going to reuse the file yeah but to reuse the file it needs to make a call to the operating system so the file system is going to say okay now this file is no longer called like this but it's a call like that like that and that pointer goes to that place, and then you get your file being reused. That takes time. It's very, very, very little time. I mean, we're talking about nanoseconds. But I mean, when you have so many files, those add to the replication lag. So then we realized that actually reusing WAL files affected synchronous replication, which is nothing to do, actually, when you think about it. Now, then when you say like, of course, of course, because we're talking about the same files, but that's post-mortem. So, of course, this is related, but then you are going to happen the same thing when you finish the book. It's like, oh, of course, this was related, but you don't see that from the beginning. And then there's another thing that Postgres does is that whenever you create a new file, so you don't want to reuse it, instead of waiting for something to write, it's going to immediately initialize it with zeros. Boom. It's going to fill in 60 megabytes of zeros. Yeah? So that is all already available to fill in with the new data. But that also takes time. That also takes a few nanoseconds or milliseconds. So in order to solve a problem of a query in the primary that takes too much time, what we needed to do was to eliminate the idea of writing zeros in the WAL files, eliminate the configuration to reuse the WAL files so that the synchronous replication was going to go faster and therefore your query was going to be faster as well. So you see all these little connections. At the end, you say, like, of course, obviously. But when we were investigating this stuff, it was not obvious at all. But then you see, I mean, some parameters are connected to other stuff even in a very, very remote way. And so it helps you solve problems.

CLAIRE: 00:26:33
But to be able to make those connections you've got to have that broad understanding of the system of all the various components of Postgres. [Yes, exactly.] And it's not just how do I execute this command or how do I tune this parameter, but you need that big picture understanding, I think. That's what I'm hearing you say. Hey, I just tried to look up your FOSDEM 20--well I don't know what year it was.

BORISS: 00:27:05
Yeah, it was last year. Yeah, but it's two editions ago. Yeah, that's why I got confused. It's two.

CLAIRE: 00:27:09
Okay, so, and you've co-presented with Derk van Veen several times. [Yeah.] So I just want to name the title of the talk I found just to make sure I'm going to get the right one for the show notes.

BORISS: 00:27:19
It's the longest one ever.

CLAIRE: 00:27:19
It says, it's very long. It says, "High available configurations are very common for PostgreSQL. But how do you investigate performance problems when the standby can't keep up?" Is that it? You think?

BORISS: 00:27:30
That's the longest title I ever worked with, but I mean this is Derk's title, I didn't create that one.

CLAIRE: 00:27:36
Oh, you're blaming him now, okay!

BORISS: 00:27:38
No I'm not blaming him, I'm applauding him, because of the brilliant idea.

CLAIRE: 00:27:42
I was teasing you. Or I was teasing him. I was teasing one of you. Okay. So speaking of connections, you're making me think of other talks that you and Derk have given, but also you and Derk are known to be, do you, you don't live in the same country, right? [No.] You live in Belgium and he lives in the Netherlands, correct? [Yes, that's correct.] But you, you will sometimes see each other at Postgres conferences because there are many in Europe and you're both co-organizers along with some other amazing people like Floor Drees and, oh, probably other people whose names are. [Teresa Lopes, Sarah Conway, Stacy, Nico. Yes.] Yes. PGDay Lowlands, which has happened twice now, and I've missed it both times. So shoot me now. But one of the things you're also known for is people will see you sitting in the corner in the hallway track at a conference playing chess. Why do so many Postgres people play chess? What's up with that?

BORISS: 00:28:43
Yes. Well, it's fun, chess, and it also has some nice life lessons, if you want to. Again, the connection. So psychologically, if you think about it, for instance, my wife, she's also learning to play chess now. And one important thing was to learn to play using a clock. I don't know how it's called in English.

CLAIRE: 00:29:09
A timer, a timer.

BORISS: 00:29:10
A timer, a timer. Because one of the problems that she has sometimes is to take the perfect decision. And then she, it's not that she procrastinates, but she evaluates a lot and a lot and a lot just to get to the perfect solution. But then if you have a timer, then you need to take a decision, even if it's not the perfect one, but with the best possible information that you have, and then take a decision. So this helps you actually to improve your decision making. Even if you make a mistake, then in chess we say either you win or you learn. I learn a lot playing with Derk, by the way. He beats me all the time. But, I mean, that's the thing. I mean, it helps you on that. There's another thing in chess that helps you about dealing with failure, for instance, when you make a mistake. If you stick with that mistake and you think, like, oh, why did I play that? Why did I play that? You're going to lose focus on the next play, and then you're going to continue losing more. So what you should be able to do is when you made a blunder, it's called, you kind of imagine yourself going out of the room, getting back, and somebody tells you, like, look, this is a board. You have to play black pieces now, and this is your position. Let's start from here. And then you have to be able to see yourself. I'm in this position at the moment. What is the best that I can do to either save the solution or win the game or get a draw or whatever. But then if you start like that, you don't think about your blunder, your mistake. So you still need to take responsibility because you still need to play the game. But I mean, if you think about the mistake, you lose focus. And this is also sometimes we have that in projects professionally. Sometimes we end up in a situation that, well, might be our fault, might be somebody else's fault, but we are in the situation anyway. So instead of blaming people or blaming yourself or blaming the mistake that you made, it's better to take this approach saying like, okay, this is my board. Now, these are the pieces that I have. This is the position that I have. How do I go from here to a successful project and then do a final good delivery? So that's what I like from chess. I don't know if everybody thinks about chess like that or some people just think about it. This is a nice competition. I want to be the best and beat everybody. But at least this is how I look at chess.

CLAIRE: 00:31:42
Your example of how chess helps you deal with failure, and I'm not a chess player, by the way, is really fascinating because, I mean, it just, it sounds like a very powerful technique to get yourself out of your head. And that's what you have to do in that situation. You cannot obsess and dwell about a past mistake or a blunder. It's not going to help you. You got to get that gone and focus on what can I do moving forward? I'll often say that, Hey, I can't change the past. All I can do is change the future. So let me focus on what I can do now to change the future. Or you're making me think about something else. I don't know. You're stimulating all these connections in my brain. But my husband had a list of things. Apparently I learned this many years later of like what he was looking for in a future spouse. This is way back when we're in our 20s. And apparently one of them was he wanted the person to be a really good downhill skier. He married me in spite of the fact that I am merely an intermediate downhill skier. I am not great. I mean, I do ski black diamonds, but with great difficulty at times. And so, you know, every year I would, to try to get a little bit better every year, every year I would take a lesson. And I remember this one instructor, I was going down this really steep black diamond, and full of moguls kind of slope, and I was struggling. And he could tell that I was upset about the last turn and the previous, previous turn and all the mistakes I'd made, you know, behind me. And he's like, "Look, every turn is a new turn. It doesn't matter what you just did. Just focus on the new turn." And that was kind of a similar advice. But I think your chess example is even better.

BORISS: 00:33:35
No, I think both are good. And that's the thing, because it creates familiarity. If I explain my chess example to a skier, you're just going to say, okay, nice, and carry on. But if you explain yours, it creates a familiarity, and that's what I think it is nice. I mean, you try to search for connections that are more direct than others, of course, but that's why your example is also very useful. I like it.

CLAIRE: 00:34:00
You said you were going to bring up perfectionism or you said maybe we can talk about it later. [Yeah.] Is now the time or did you mean later, like after the podcast is over?

BORISS: 00:34:09
No, no, no. So let me see. So this is a connection between perfectionism, Darwin evolution, and Postgres releases. Do you like that?

CLAIRE: 00:34:18
Okay, let's go.

BORISS: 00:34:21
I started to think about this and then I came up with the connection with this. So there are people that struggle, really struggle with perfectionism. It's not just like saying like, okay, this is my defect, but then you turn it into an advantage. Now, people really, really struggle with perfectionism and it creates a lot of problems. And then some of the advice that I've heard about helping people with perfectionism is to tell them that perfection doesn't exist. And they can repeat it like perfection doesn't exist. But I don't think it helps because imagine that you are a perfectionist, Claire, and I tell you perfection doesn't exist. In your mind, you're going to think like, oh, wait, you haven't seen anything yet because you are a perfectionist. because you're targeting perfectionism.

CLAIRE: 00:35:03
Yeah, yeah, I would think, no, that's baloney. And I wouldn't use the word baloney. [Yeah.] I would use a more colorful word, but yeah. [Right.] Okay.

BORISS: 00:35:11
But then even if you accept that, okay, perfection doesn't exist, that is going to be so frustrating because you're seeking for perfection. And then either you say like, wait and see, or you're like, I'm down now because I will never reach my goal. So I turn this around, and in order to help somebody, I tell them, look, perfection might exist, but perfection is overrated. And that changes, you see, because even if you seek for it, and then if you find it, might not be actually a good thing. Perfection is overrated. This is my message to people that suffer for perfectionism. And let me explain you why. So let me go now to Darwinian evolution. A perfect clone of DNA is just going to create exactly the same cell, with exactly the same properties and exactly the same features, but it's not going to evolve. It's never going to change anything because it's a perfect copy of DNA. You can say, okay, of course, but evolution happens because there are a pair that they mix their DNA. Well, this that came after. In the beginning, there were only cells that were reproducing themselves. So actually evolution comes from imperfect copy of DNA. Imperfection in the copy of DNA is at the core of evolution. And we know that Darwinian evolution is an explanation for many good things that has happened in our life. So maybe a perfect copy of your DNA is not as good as an imperfect copy because otherwise you don't evolve. And then we came back to, as you see, perfection is actually overrated. Sometimes you need this imperfection stuff. But then somebody can say, well, well, well, but you're looking at that because you want to show it like that. Because the beauty of evolution, the perfection of evolution is this modification of the DNA. That means that I'm giving a different explanation of perfectionism in terms of Darwinian evolution, discarding perfect copy. That means that I gave you two definitions for something that is perfect, meaning that perfect, in this case, is subjective. This is, this is, if perfection is subjective, I mean, I could even continue finding other ways of defining something that is perfect. And then we ended up saying it's actually overrated. Why do we search perfection if it can be subjective? Which is kind of a contradiction. I mean, perfection shouldn't be subjective. So there you go. I think that perfection is overrated. Now.

CLAIRE: 00:37:43
Okay, well Chris Ellis would say that perfection is the enemy of the good.

BORISS: 00:37:51
Exactly. Perfect.

CLAIRE: 00:37:52
And you you're reminding me of a story about the perfect paper where you know somebody working on a team was given an assignment and this was not in the context of Postgres but it could be easily. And they went off in search of creating the perfect paper. And as a result of trying to make the paper perfect, you know, they didn't deliver it for, they could have delivered it two months earlier. And they didn't, right? Because they kept trying to make it perfect, make it perfect. They worked on it kind of in their own tower, in their own office, by themselves, trying to make it perfect. And it didn't come out for two months. And then of course, it wasn't nearly as relevant. And so that's actually why I'm a fan, even though there's part of me that struggles with perfectionism, of getting out really crappy first drafts earlier rather than later, so that I start getting other people's inputs, ideas, eyeballs, criticisms, whatever, right? The only way I'm going to make it good is to expose it to sunlight and eyeballs and get feedback.

BORISS: 00:39:00
Yeah, I love it. I love it. And that's actually the connection, that's the connection actually that I wanted to make with Postgres releases. Because if you listen to the previous episode, Andres Freund, he said that asynchronous I/O is only for read stuff at the moment. And you were surprised, like, oh, it's only for read? It's not ready for write yet? I said, no, this is coming maybe in the next release. So it's not a perfect Async I/O, but that's why it's released, you know. If we would have been waiting for the perfect development of that, it wouldn't be available now to test. And this happens also with other stuff, like table partitioning. Table partitioning, the first release, I think it was Postgres 10. It really was very basic. It didn't have the perfect features. And then many, many things were added. I think Postgres 12 is probably the one that people would say, yeah, now it's really partition ready and stuff like that. Same thing happened with JSON objects that first were just plain JSON and then JSONB with binary stuff and then you could index fields. And so it is growing and growing and growing. It was never a perfect release of JSON support. Same thing with logical replication. I mean, we were discussing about Active-Active. The first thing that was released was just logical decoding, very far away of just having logical replication by itself. And then now we are super excited and happy because we have Active-Active, but we still don't even have replication of DDLs. So none of those releases is perfect, but we have them and we use them and they are good enough. I'm not saying that we should be releasing crappy stuff and buggy stuff. I mean, if you know that you have a bug, you have to do your best to fix it. But then when it's good enough, then you can release it and don't wait for the perfect release because it might be subjective your definition of perfection and therefore I think it's overrated.

CLAIRE: 00:40:53
Well one of the things that Andres explained which I thought was really interesting I mean The project itself, asynchronous I/O in Postgres, it's a multi-year project. He's been working on it more than five years in collaboration with other Postgres developers as well. And in addition to being a big, audacious architectural change to Postgres, there were also challenges like what you're talking about with Postgres releases to figure out, like, well, what piece can go into Postgres 16? What piece is in Postgres 17? What's going in 18? What's going to go in 19, to carve it up in a way that was feasible. And in particular, there's, well, I don't know if it's a rule in Postgres, but certainly there seems to be a best practice where, you know, if you're going to integrate something, a new capability, it can't just sit there on the shelf of a release. There has to be a user for it. There has to be a component that is taking advantage of that new capability. And so, you know, they couldn't just put the code in and have and wait, they had to make sure that something like vacuum, for example, or sequential scans or whatever was taking advantage of that new feature. And so I just thought that aspect of architecting the integration of async I/O was kind of interesting. And in the episode, this wasn't the talk he gave in New York City. The talk he gave in New York City was 100% geared toward users. And what are you going to get out of Async I/O and Postgres 18? And let me show you some performance benchmark results that, you know, he's run. And that was great. But what he talked about on the podcast episode was more a reflection on what went wrong and what went right with the project. And I was very, I was interested to see how Andres felt about it and what he felt proud of and what he was frustrated by. And it's just, he was very open.

BORISS: 00:42:52
Yeah, nice. I like that episode. It also, there's some similarities with the presentation of Melanie in New York as well, when she went through all the attempts to improve vacuum freezing, and then again getting very excited about a possibility, and then finally realized that it doesn't really help, and stuff like that. So that was also super interesting. She said that she got very frustrated while working on that, but I mean, there are many, many lessons learned from that. And it's going to prevent all the people in the future to go through the same path because she has documented it and then presented it in a conference. This actually made me think about Ludwig van Beethoven. He is considered one of the major composers of all times, of course. And now there was one episode that I learned about the Fifth Symphony, which is my favorite one. In the second movement, he wrote 17 drafts of the initial melody for that movement. 17 drafts. Imagine how many titles you suggest to do for a talk. I think you suggest seven or ten. [Oh, ten to fifteen. Yeah.] He still does 17 drafts for a second movement of a symphony. Finally he picked up the best and he was not a perfectionist. Some people claim it, but I mean, he would never really release a perfect stuff. He was even struggling with some deadlines. But I mean, that shows you that when you care about something, you do a very big effort. And then, yeah, I don't understand why some people just claim to fame that they just write their presentation at once and then they present it. I mean, this is when you see good quality work, you can see that there are many, many attempts, which is again, getting back to the idea of being open to failure. And, I mean, you could see that, you can count that Beethoven made 16 failed attempts to write a second movement of a symphony. You can put it like that. But I mean, you don't have to focus on the failure. You need to accept the failure as part of the creative process.

CLAIRE: 00:45:05
Well, I don't see 17 drafts as indicative of perfectionism in any way. I think anybody who's a creator, who creates things that are then, well, they're not all going to succeed. Some are going to fail, like you say, but creates things that delight people at the end of the day. Okay. So I've been listening to the new Taylor Swift album, The Life of a Showgirl on repeat for the last couple of days because it just came out last Thursday night, right after PG Conf NYC. And, but anyone who creates that, I've got to believe there was so much iteration, right? In improvement and iterate and iterate. And I think that whole edit cycle, that whole creative process of tweaking and adjusting and making better and is, I don't know. I don't see that as perfectionism. I see that as the creative process. [Yes.] It's fun. If, if you find something that you like creating, I firmly believe that Andres Freund really enjoys working on Postgres. I know Melanie Plageman really enjoys, you know, working on Postgres and that, that talk she gave, I dropped, I'll drop a link into the show notes, about improving freezing and Postgres vacuum from idea to commit. You could see her, her commitment to making that thing better as she gave that talk. And there was definitely a lot of edit cycle in there. I think she would definitely say there were more than 17 drafts along the way.

BORISS: 00:46:42
That could be, yes. Yeah. No, very interesting.

CLAIRE: 00:46:51
Okay. So you brought up Beethoven. [Yes.] I think you brought up, well, I don't know why you brought up Beethoven. I'm not going to presume to read your mind, but I do know this. You're a musician. [Yes.] Does music and your love of music, I mean, you're actually known for your fondness of a type of music called metal. [Yes.] Maybe you're going to have to define that for people. But then the second question, so after you define it, the second question is, does your love of music make you better or worse or at all influence your work on Postgres.

BORISS: 00:47:26
Well, there is definitely a connection. I mean, because the music is connected to me in my day-to-day activities, Sometimes silence is part of what I need, but it definitely impacts my mood. So it helps me to... Definitely heavy metal music helps me to lift up my mood when I need it or channel my anger sometimes. But also to make me happy. When I listen to power metal, I get happy. Also, I think it's good for your health because you start moving. When you play air guitar, it's like dancing basically. So you kind of get some movement during the day. But I mean, it's not just the music in itself, but also the process of the creative process of, like I was mentioning Beethoven, basically because it inspires me in the creation of process. And also because it's a collaboration. When you play music or when you listen to music, this is a communication from the musician to the other people that are listening. Or in the case of jam sessions and stuff like that, it's a communication between the musicians about moods and feelings and stuff like that. So it is a mean to communicate, which is connected to the fact that we are humans. And then this is the human side of Postgres in your podcast. When we work in a project, even if you're working just with code, as you were mentioning, when you propose something for Postgres, They have to be a user, a use case. And behind that use case, there are humans that are on the other side. So this is also the same way that you are connecting with those people. There are some type of music that just try to show off that you are super smart and that you can play very complex stuff. And that kind of be kind of like appreciated like, oh, wow, well played. But it kind of ends there. I mean, there's no connection that happens in a long term. It happens for that moment. In the same way, when you produce software or releases or a solution architecture, you do it because you're building up something for somebody else who is going to use it in the long term, hopefully. So you're solving problems for people. You're not just solving technical stuff. I mean, some people just focus on the technical stuff and that's it. But I mean, there's always somebody who is using that solution at the end. And I think that that's a little bit the connection in terms of how to approach work and solution. And the other connection, which is more obvious, I would say, is the community in Postgres. Because Postgres community is where we kind of take away the technical part, but we just talk about the people and then how the people collaborate in general, regardless of the fact that they're working on code, or they're working on preparing a conference, or they're working on preparing a presentation. So the music in itself is definitely connected to the community, I would say, of Postgres. Is that the kind of connection that you were searching for, Claire?

CLAIRE: 00:50:30
There's no there's no right or wrong, there are so many directions or pivot points or jumping off points you could have gone from my question because it was pretty open-ended, but I wondered if in talking about music you were going to bring up the talk you gave at PGConf NYC, which by the way, I want to see you give it again. I want to see it recorded. I want to see it submitted to other conferences. Those of us who were in the room found it so powerful and it was called Database Modeling and the New York City Jazz Scene. [Yes.] And what was cool about it, and this reminds me a little bit of, oh, I'll think of a talk that somebody gave years ago where I think when you're giving code samples in a talk, it's so much more interesting when the use case that you're describing is something real and visible and understandable. And so your use case, you were talking about the New York City jazz scene, and you actually put the posters up of these venues and these different performances in these dates, And then you showed us how you could build a data model for them. And you walked through it kind of step by step. And you went through all the glitches, all the "uh-oh, uh-oh, this doesn't work. Uh-oh, how are we going to incorporate this? Uh-oh, here's a surprise. Various artists, what do we do with those?" Excuse me. And it was really, really interesting. But then it led to, I think somebody walked up to you afterwards, and they actually work in media and entertainment. [Yes.] And I don't know. Tell me what they said.

BORISS: 00:52:17
Yeah, so he said, oh, that's exactly what we do in our solution. You nailed it. He said, that's definitely what we do. This is how we solve that problem. So I was super happy that doing this presentation, I tried to make it as realistic as possible in the sense that you start with a problem like you want to study the jazz scene in New York. So you go from the musicians, the venues, when they play and all this kind of information that you get, where the venue is located, whether the venue is open or closed, whether the venue went through a period that couldn't be open. So those kind of questions kind of, right, We try to bridge that real-life scenario to a database modeling. Which tables you want to use, which is entity relationship, then you see, again, entities, connection between entities, and then which data types are best, which guarantees you need to offer, which guarantees translates into constraint. And so one thing is I really like the fact that I managed to provide something that was a realistic solution because the guy came in and said, this is exactly what we do. But also the questions that I got, I mean, there was a question from Chelsea, which was very technical, about the performance of the array. But then there were other questions also coming from Chelsea and other people about what if this happened in the New York scene? How would you represent that in your data modeling? So what I like from that is that people started thinking about bridging from real case into a data model of a database, which is what I was trying to inspire with the presentation. Not just looking at database modeling, what are the data types and whatever you can use, but really doing this bridge because I think the solutions have to be for real use cases.

CLAIRE: 00:54:00
Well, and I think if you had done the classic foo, bar, a, b, you know, variable names that were just generic and boring, people would have been surreptitiously glancing at their phones. You know, it was your use of this vibrant, beautiful example. And you had some fabulous posters in there and some little segues and stories about some of these musicians and the jazz scene. But the best part, and I only know this because we are lucky enough to be friends, is that later after the conference was over like one or two days later you actually went to some New York city jazz clubs in Harlem right?

BORISS: 00:54:44
That's correct yes so last time there was in New York I was like kind of less than 48 hours and they say, okay, it was a pity because I couldn't really experience the city and the people. So now because I was talking about the New York jazz scene, actually suggested by Chelsea Dole, this idea, I said, okay, well, maybe I can stay one extra day on my own and then I can go to see that life, I mean, and experience that. And it was such a nice thing because first I went to the Jazz Museum in Harlem and they were so welcoming. They immediately said, oh, so welcome to our museum. Here you can explore this part, this part and then say, okay, well, thank you. And I'm actually searching for Jazz clubs. Oh yeah, we have here this list of Jazz clubs. Where do you want to go? And I suggest, well, something here, walking distance because I'm here. Oh, then I will suggest you this place called Patrick's Place. It's very casual. Or if you want to go to a different mall, like other stuff, they will suggest another stuff. So very, very informative and welcoming. And this is actually that we were discussing about the Postgres community, that this is what we want to generate as well. That's happened to me when I joined the community, by the way, very welcoming people. And then I went to the to the Jazz club. And immediately when I arrived, it was like, oh, you're coming from the music club, please come in. And then I could talk to the musicians a little bit and they play a set. They were jamming. I was observing how the jam session is actually organized, how they communicate between them when they switch from one solo to the other solo. And in between sets, I was talking to the guitar player and he asked me, well, do you play something? And then I started talking about the band that we have here in Belgium and the type of music that we play, which is South American music, a different type of guitar and different style and everything. And it's funny because I told him, we play folk music. And he said, isn't all music folk music? Because it's coming from the people. I really like that because he was saying that jazz is also folk music, you know. And at a certain moment, he asked me, do you play electric guitar? I said, well, I haven't done it in years, but I mean, I can try. Okay, good, because I also have my flute here. So I can play flute, you can play the guitar. So they invited me to go and play. And I play a song with them. They're used to this. They do jam sessions all the time. So they're used to it. I mean, in the Postgres community, we are also used to discuss topics and stuff like that. So nothing prevented from involving newcomers into discussions that are relevant for the newcomers. I mean, this was super relevant for me because I felt like a real musician playing with these pros. And I set up the tune, actually. I said, okay, well, they told me, you play your form and then we follow. And it was such a nice experience. I was lucky that I hit the record button on my phone. So I have the audio of that. And I'm super happy with that. But then this is a connection that you can build up with people when they are open to welcome new people in their community. So that was a very nice experience. I hope that this is how people feel when they go to our conferences, when they go for the first time, that they are part of something that they feel welcome, that would be nice if somebody... Well, we have heard that from time to time that people are super feeling welcome. Sometimes we also feel people that say, okay, I'm never coming back and stuff like that. But that's the connection. [Oh.] Yeah.

CLAIRE: 00:58:03
I will say that a lot of the people I know in the Postgres community who participate in these in-person conferences do bend over backwards to try to make newcomers, excuse me, feel welcome. [Yeah.] And so I think it's certainly what we aspire to. And I hope that anyone listening who has not yet been to a Postgres in-person community conference and goes and tries it out will have that experience. It certainly was my experience starting in Lisbon [Yeah.] with you as my room host that time.

BORISS: 00:58:42
Nice. Now, of course, they didn't put the guitar in my hands, and I was forced to play. No, I mean, I also started the conversation with them and chatting. I mean, there is always an effort that comes from both sides. But the reason that I did is because they were welcoming in the first place. So I think that's the thing. We need to open the community by being welcome. I mean, we do it already quite a lot, but I mean, we can still do it even better, I think. Yes.

CLAIRE: 00:59:10
So I mentioned at the beginning of this episode, I think, that this is episode 32. And so I've been recording this podcast now for almost two and a half years. And in the beginning, it wasn't a podcast yet. We didn't know what it was going to become. And it certainly didn't have that introductory and finishing music at the beginning and the end of each episode. And I don't know when it was, six months ago, seven months ago, finally said, okay, we got to have music, right? That is a missing component that is necessary. And so I collaborated with Isaac Alves, who's someone I've worked with for years. And he went off and found different clips of music. And we talked about them and explored them. But when it came down to making the decision and looking at the final few choices, Boriss, I have to thank you because you shared a couple of options with you. And you gave me such interesting feedback. And the reason that we picked the music that we did for Talking Postgres is actually because of something you said. And you talked about how that you felt like the instruments were speaking to each other, like in a conversation, which is kind of exactly what we're doing. [Yes, exactly.] And the second I heard that, the decision was done. I'm like, OK, I'm going with this.

BORISS: 01:00:28
I'm happy to hear that. [And yeah.] Good. Yeah, there is a relationship definitely with music and connection between people. Something maybe I can also like to mention is in New York, I also gave a lightning talk, which is inspired by the welcome speech that I gave in Lowlands a few weeks earlier that I thought, okay, this could be [You mean PGDay?] PGDay Lowlands, PGDay Lowlands, yes. I thought, okay, this could be turned to, because I get good feedback from that one. And I said, okay, maybe this one can be turned into a lightning talk. And I expanded a little bit and I presented that in New York City, which comes from making the connection between how some sort of animals collaborate between them, like the wolves and then also the elephants, and then saying that this is part of their instinct, but then as human beings we have a choice. And then it referred to the work of Viktor Frankl, which compares a mass of people versus a community of people. And when he says that a mass of people is taking every component, like a group of stones where you could replace every stone by any other, regardless of which stone you're replacing, because they're all exactly the same. Some kind of group of people try to do that, like you have replaceable members. And for their goals, it might work. But when you have a community, it's more like a... And here you have to help me again, Claire, a mosaic.

CLAIRE: 01:02:01
Mosaic.

BORISS: 01:02:02
Because there, every stone has its own particular color and shape and position that makes the figure a piece of art and not just any group of stones. And then Viktor Frankl goes further and then it says like the community actually gets its meaning through the uniqueness of each of its members. and that each member is going to be able to shine through the community, establishing the connection of the members. Let's see, we get back to the connection again. And this is true in the sense of, for instance, when you have a lot of knowledge and you are a man that lives in the mountains and doesn't talk to anybody. I mean, you can still have a happy life and be happy with yourself, but then to shine, it is when you are able to share that knowledge with other people. And actually, all the stories that we heard about these hermits people is when they get in contact with other people and then they share their wisdom. So it's not when they are thinking of themselves and then they gave an answer to themselves about a very important question. So the same thing happened with individuals in the Postgres community. We need to understand what makes us different and bring that to the community so that we can actually shine through the community. And the same happened with musicians. I mean, when a musician is playing on his own, I mean, it's nice for himself or herself, but then you establish a connection where you can play for somebody else. And that's actually makes it more light that connects the pieces. So I like that.

CLAIRE: 01:03:37
And just just to explain a little bit I think because I saw your lightning talk in New York City I have this context which I want to share with the listeners which is that PGDay Lowlands which is what inspired you to give this lightning talk in New York City about how these animals are collaborating and the connections to communities of people, PGDay Lowlands took place at a zoo in Rotterdam this year, which is kind of what inspired you to look at the elephants and the wolf packs and things like that, right? That wasn't a coincidence, was it?

BORISS: 01:04:15
No, exactly. But then again, we get back to the presentation that you mentioned of last year in Greece when I was looking at the Sparta government. Because, I mean, I try to give context and then try to give familiarity. And what we were saying, then Dirk Gently that has his eye open for connection. You can also search for that stuff. It's not just about discovery, but you can also intentionally search for that connection. Sometimes it just doesn't work and you say, well, there's nothing here that I can use. But when it happens, it's nice because it generates this familiarity and then it makes things more easier to remember. And that's why when you want to share some knowledge, you want the other people to remember it. There are some things that you want them to remember and some things that you don't want them to remember, or that you don't force them to remember. For instance, there is this song from another metal band, Blind Guardian, which talks about The Bard's Song. In The Bard's Song they say that the stories told by the bards in medieval times that were told from person to person, we remember the stories, but nobody remembers the name of the one who told the story. And that makes you understand that as a speaker, your message is more relevant than your own name. So if somebody remembers what you presented in a talk, but they don't remember that it was you who presented it, do you still feel the value or not? I feel the value. Some people want to be remembered, and that's also fine. I'm just saying that for me, what connects me more is that my message gets remembered. So I feel like The Bard's Song. When I listen to The Bard's Song, I feel very much connected with the song because of that. So that's nice. That happened to me once. [I mean...] Somebody explained me an algorithm for peer-to-peer, And I said, well, I wrote that. That's my paper. Oh, you wrote that paper. So that's cool because they didn't remember that they were talking to the author of the idea. But they explained the idea to me, which is super nice. I mean, that means that the idea was more relevant than my name, which is good. I like that.

CLAIRE: 01:06:24
Well, and I think it's pretty obvious for people like you who are committed to, you know, helping other people learn Postgres, helping other people get better at either using this technology or contributing to this community. It's pretty obvious that you are trying to give people takeaways, you know? So they leave and remember something that makes their day-to-day life better. And so, yeah, I agree with you. I don't care if they remember my name. For the people who are in the room at the, I gave this 10 Postgres Hacker Journeys and What They Teach Us Talk in New York City, I just hope that the people who were in the room walked away with one of the stories that'll help them in their jobs. [Yeah, and that would inspire them, like...] They can forget my name. Who cares?

BORISS: 01:07:12
Yeah. They can inspire them also to go do something.

CLAIRE: 01:07:17
Yeah, okay so The Fundamental Interconnectedness of All Things, is there anything else you wish I had asked you about or you want to talk about on the podcast before we wrap?

BORISS: 01:07:35
Yeah, there are two things. So let me get back to the lightning talk. I mentioned in that lightning talk...

CLAIRE: 01:07:41
Did I cut you off?

BORISS: 01:07:42
No, no, no, no, not at all, not at all, not at all, because this something extra. So I started work from The Jungle Book, The Elephant Rescue System in Africa, I don't remember the name, also Viktor Frankl. I also mentioned an anthropologist called Margaret Mead. So none of this stuff is my own investigation. The only thing that I did was to glue them together into a message. And then I want to get back to this idea in the beginning that a system is larger than the sum of all the parts. And because making this line between all these things and connecting them, it is my contribution, not each of the researchers. Actually, one of the researchers from Rutger Bregman that I mentioned there, which is fantastic. So when I was doing the PhD, what we used to say, If you steal something from one author, it's called plagiarism. If you steal from many, it's called a thesis. But the thesis also has to come with a proposal. So you kind of connect all the work that's your capita selecta or state of the art. And then you come up with something new based on that. But I mean, you still need to base your work on some other stuff. But then again, it's how you connect all these different ideas, also part of a contribution. Because what I did in the lightning talk was not presenting anything original for me. I just connected them. So that's what I wanted to add.

CLAIRE: 01:09:06
I like it, The Fundamental Interconnectedness of All Things. Okay so a couple other things I dropped a link I will drop a link to PGDay Lowlands in the speaker notes for someone who is nearby in Europe, who is listening, who'd never heard of that fairly new event because it's only happened two years in a row now is there going to be a PGDay Lowlands year number three [Absolutely.] next September [Absolutely.] not announced yet but there will be one right so people can like...

BORISS: 01:09:40
No it is announced, [It's already announced? Okay.] it's 10th of September in Utrecht. Well it is informally announced we said it on the event itself so it's recorded in the live stream so people can watch the live stream by the way on YouTube if you search for it and it's going to be in a special venue. It's not going to be in a zoo again but it's going to be in a special venue. [Okay.] The second best Postgres conference in Europe.

CLAIRE: 01:10:06
Second to?

BORISS: 01:10:08
That's the thing, people can argue about the first one, but nobody argues about the second one. It's funny. If I would say the best conference, people would say, "No, no, it's not the best." But if you say second best, people agree.

CLAIRE: 01:10:18
Okay. Two other things. Do you happen to have a cheese story? Ever since David Rowley was on the podcast, and that was August of 2024, and he talked about how he got his start in Postgres, And it involved a forklift and a cheese factory. And now, of course, he's one of the top performance optimizing Postgres committers in the world. And I say one of because there's, you know, other people who are really good at that, too. But do you do you happen to have an interesting cheese and Postgres story? [That's funny.] Is there a connection?

BORISS: 01:10:55
That's funny because I prepared your other question, but I didn't prepare this one. But as soon as you mentioned cheese and we were talking about community, immediately came something to my mind. So I organized a conference for Alfresco, which is a content management system and commercial open source that uses Postgres, by the way, as one of the database. And then this was in Brussels, but it was on a Thursday or Friday. And then on Saturday, what we did is that I organized a trip to Bruges, or Brugge in Dutch, which is a medieval city, fantastic city. If we ever do PGDay Lowlands in Flanders, probably Bruges or Ghent is going to be one of the cities that we want to visit. So we went there and we walked with the people from the event that managed to stay until Saturday. And I brought them to a brewery, which is called De Halve Maan, the Half Moon. And then I order beer and cheese. And the Swiss people from Switzerland, they would say, what are you doing? I mean, cheese should be consumed, you get it with wine. You don't mix it. [White wine specifically.] Well, it depends. I mean, in Chile, I think we use Red wine Carménère. I think it's very good for cheese. But anyway, they were quite surprised. Luckily, I mean, like every good open source people, they were open for surprises. And they were, they were like, okay, well, let's give it a try. And they were fascinated by the combination because this is served together in Belgium. There are some beers that combines really, really, really, really, really good with some type of cheese. And they were amazed by that. They said, okay, well, I never expected this, but now I've changed my mind. And I think this is some of the interesting features when I connect to people, it is usually people who is able to change their mind upon evidence. I mean, I try to do that as well. When I realize that I'm wrong, I say, okay, fine. I discovered something new. I've learned something. And the same way when you learn by missing a movement in chess. So, yeah, they were super happy to experience the beer and the cheese together. So next time you come to Belgium, I will show you that as well. anybody who comes to Belgium, I can guide you a little bit in that.

CLAIRE: 01:13:18
Okay.

BORISS: 01:13:19
It's a valid cheese story?

CLAIRE: 01:13:22
After the show, if you help me figure out how to spell Bruges, and tell me the name of a good beer and cheese combination, I will include it in the show notes as an extra piece of value for anybody who's listening. Okay, last question for you. And this can relate to the fundamental interconnectedness of all things or not. It's up to you. But do you have any advice that you would tell past Boriss, [Yes.] your past self, or advice you want to offer your future self so that when you listen to the show again in three years, there's something waiting for you?

BORISS: 01:14:07
No, to my past. I would say to my past self to be more open to failure. Don't be scared to break things. Don't be scared to failure. That's something that I learned after. It's not something that I learned. I was lucky with my parents. My parents were super nice in that sense. But I grew up in Chile in a dictatorship. And everything was really militarized. And then mistakes were penalized a lot. I mean, you hear people that manage to develop skills by discipline. For me, the word discipline, it meant follow the rules, obey what I'm saying. Then I understand that when the people talk about discipline, they talk about self-discipline, which is a positive thing. I like self-discipline when I myself decide what I want to do and I have my discipline to get to that. But when I grew up, discipline was like, say what I do and don't do any deviation from what I'm saying. So I was really scared about failure in general. Luckily, my parents were not like that. So that kind of opened my mind to be able to accept failure and be... That opens my mind for creativity, actually. If you're not open for failure, you cannot be creative. If you can just solve... People say, in this company, we work for innovation. Well, then you need to accept that people make mistakes and fail and stuff. If you don't accept that, then you're never going to do something different and never going to be able to create something new and original. So, yeah, I will tell to myself, accept failure not as something that should be penalized, but as something that is open for creativity. It's the only way to get creative is by failing, I think.

CLAIRE: 01:15:53
I like it. And I think that's a perfect note on which to close up today's episode. Boriss, thank you so much for joining us.

BORISS: 01:16:05
My pleasure.

CLAIRE: 01:16:06
For those of you who are listening, if you liked today's episode and you want to hear more of Talking Postgres, you should subscribe on Apple, Spotify, YouTube, or wherever you get your podcasts. And please tell your friends because word of mouth is one of the best ways for people to discover a show like this. You can get to past episodes and get links to subscribe on the various podcast platforms at TalkingPostgres.com. And transcripts are included, really good transcripts, on the episode pages on TalkingPostgres.com too. And a big thank you to everybody who joined the live recording and participated in the live text chat on Discord today.