Talking Postgres with Claire Giordano

Becoming expert at using PostgreSQL
===

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 many PG extensions. I wanna say thank you to the team at Microsoft for sponsoring this community conversation. And I'm Claire Giordano.

PINO: And I'm Pino de Candia.

Today's topic is becoming expert at using PostgreSQL

CLAIRE: And it is my pleasure to introduce Chris Ellis today. Chris is head of engineering at Nexteam, which is based in London, in the UK, and Chris has been working with Postgres for 18 years. I think he first you first started with Postgres 8. Is that right, Chris?

CHRIS: Yeah, about that, I think.

CLAIRE: And Chris is a regular on the Postgres conference circuit. That's actually how I first met him. And he's also involved in organizing some of the Postgres community conferences these days. Welcome, Chris.

CHRIS: Thank you much. It's great to be here and thanks for the invite and really excited and interested.

CLAIRE: I am too. All right. So, so let's dive in. We have so many questions about how you built up your expertise in Postgres as a user and then what made you get involved in the Postgres community. But I really want to start with how you became more and more expert over the years at using Postgres and taking advantage of its capabilities.

And before we do that I, let me just ask a basic question. Like, what is it that you do at Nexteam and how is Postgres part of that?

CHRIS: Yeah. So Nexteam is a bit of a general consultancy that me and a couple of friends set up. And we're a full product stack to go and build apps for people.

But the other side of what we do is just more general consultancy. So we've got a number of small clients. I do Postgres support and consultancy work for, and then another stream is more on the building our own apps ourselves. So we have a platform called Mokuso, which is a simple management app that we build and that's all using Postgres as its backend under the hood. So yeah, all different three different angles of using it on different projects across the years, and then our own projects we build, as well as supporting other people from using it.

CLAIRE: Awesome

So so let's step back further, let's go to your origin story. People have given me so much feedback that they're always fascinated about how do people get their start or why Postgres or why open source?

So how did you get started as a developer?

CHRIS: Yeah, so, I mean, a large element of it is, is a bit of like, I always had computers around me as a kid, and always been quite curious and fiddling with stuff, so I probably started programming really in QBASIC on MS-DOS on a 486 back in the mid to early 90's, when I was 5 or 6 type thing. Just playing around, that curiosity and I guess helped, by having my parents who both have scientific backgrounds and worked in IT—as well that I always had access to them to push me and nudge me a little bit. And I was always busy building stuff and fiddling with things from a very early age and that curiosity and that stuff and over the years I can then segued into visual basic really as you do.

And I properly started using Linux and a lot of that stuff when I was around 12, it what we call secondary school here in the UK and that piqued my curiosity a lot more. I was running DNS servers when I was 12, and getting cease and desist because we use the internet too much, these are the days of 56k dial-up and things.

And then segued into Perl, wrote a few things with Perl against MySQL and then yeah, I'm not entirely sure really where the "you should go and try Postgres" came from, but it was to some extent an element of "it's more free" and "better than MySQL" so you can go and try and play with it.

So I did. And that was probably when I was, say 17 ish, I think. And I pretty much never looked back, it's one of those things I just started playing with. And then I built some little apps when I was at university with it at the same time. Whilst at university, I also worked as a professional programmer.

So I actually studied electronic engineering rather than computer science. Although a couple of my close friends at university were in computer science. So it was a very interesting perspective, working as a paid programmer in my university holidays. And then chatting to my friends at university about, they're learning the theory and then I was already practicing real world programming to some extent.

So it was an interesting world: I'd go and spend a term at university learning in electronics, low level circuit type stuff. And then I guess spend the Christmas holidays and April and April break and summer break actually coding on real world stuff in Java.

I taught myself Java in two weeks. So the first job and that was how I got properly started as a developer at that point. And it's been my job really ever since then. So it's one of those things where it's as much a hobby and a passion as it is a job.

That's how it all really sort of started. And bits of it are by accident, bits of it are my mom saying, "Oh, you've got six months, go and get yourself a job before you go to university" and stuff.

PINO: I have two follow up questions if you don't mind. For someone who started so early as a developer and, hosting and managing your own Linux servers, who did you rely on when you had questions? Was it your parents? Friends? Siblings? Who'd you go to?

CHRIS: Yeah, I think also back then, magazines were a bigger thing than they were, than they are now. Right. So I always, I was probably, they're probably still my parents left a stack of Linux user developer magazines they used to very religiously buy. And back in that era, like the big distro was Mandrake Linux, then got renamed Mandriva.

And they got a lot of their early users by sponsoring magazines and putting a CD on the magazines and stuff. And so it was a large element of those publications. And I guess, the internet is a thing at that point. Also man pages, right?

I mean, so much, you could just... everybody forgets, you can just type "man". And then the program you're playing with, there's actually quite good documentation. Especially for buying DNS servers, the man pages are actually pretty good.

And then also, I guess as well, my dad was never really a big Linux user or anything. I mean, he used to run the Novell user group. So he was much more of a Novell network person. And we did at one point have a Novell server in the house that we were playing with, that me and him set up. So it was an element of learning from peers, hands on—as well as also just going and doing my own research, and looking stuff up, and reading different, short form data sources.

PINO: That's fantastic. My second question really is just a follow up on this idea of getting started on user groups, or question boards and mailing lists early on—and developing that muscle of talking to the community.

CHRIS: Yeah, I mean. I definitely remember my first ever email to the Postgres mailing list, which was at my first job after I finished university.

And I mean, I'd been subscribed and reading the list probably for a few years at that point. Right. And we were deploying a new server was actually a full-on search engine for our website. And so one of the big drivers had been, well, can we spend a bit more money on the hardware, and have something decent?

And so we bought these IBM servers because that was an IBM shop. And performance wasn't quite as we expected. And my first big post asking for help was "we've got this hardware." I can't get my benchmarks showing these absolutely disastrous numbers, it doesn't seem to make much sense. Am I doing something completely stupid here or what?

And I think I had a really great reply from a guy called Scott Marlowe I think, which was cool, he said to call IBM and tell them to pick up your boat anchors. And, as well as some practical advice, but it was a great example of, you can actually just sit and consume stuff off mailing lists for quite a long time.

And you don't feel you have to join a mailing list just to ask a question or just to interact, right? You can use a mailing list as an information and knowledge source. And I think the Postgres hackers list is a great example of that, where it's an extremely high volume list, so you can't really read out anything. But if you want to find some interesting nitty gritty about low level stuff in Postgres it's pretty much one of the better places to go, if you can sit and wade through reams and reams of low-level arguments about stuff.

And there's definitely no place where I've learned a lot over the years has been consuming those lists more so than say, asking questions or answering questions on them.

CLAIRE: Rob Treat just linked to your first thread on the Postgres mailing list. So it's in the chat, it'll be in the show notes as a piece of history. Okay. So I want to make sure we don't scare anybody off for people who are listening to this and did not start working with code at the age of 5 or 6, right—or not running DNS servers, did you say at the age of 12? You're a combination of university trained, but even more so self taught, right? So

CHRIS: I'd consider myself more self taught.

CLAIRE: Well, so here's the question, those friends of yours who had more traditional training in university, right. And [who] weren't self taught from the age of 5 and with parents nudging them in the background... Have they thrived in the tech world? Is there another, are there other paths into the tech world?

Do you have to start at the age of 5?

CHRIS: No. Especially my first job, which was local government, there were loads of people there who actually hadn't been to university at all. And I do think one of the things the tech industry at times forgets about is that there are plenty of people who are very capable programmers and who are very good developers who don't have a degree and especially don't have a computer science degree.

I mean, I don't have a computer science degree. And I actually partially think pretty much everything I do day-to-day is all self taught, and none of it was actually really from my university side. I think one of the interesting caveats I would say is that I tend to find people who do computer science degrees don't have all of the qualities of, you know, what is engineering.

I think the ability to take your knowledge and skills and apply practically is an interesting side where people actually who maybe don't have those very straight computer science degrees can actually be better at applying how to go and use stuff and how to go and do stuff.

I'm probably a fairly good example of that in a lot of my talks. And a lot of how I understand and internalize bits of Postgres is probably very different to somebody who has a mathematics degree or an actual say computer science degree, where I think they're much more likely to talk about the theory and stuff going on behind it and things like sets and all that stuff.

Whereas I'm much more likely to approach it and think about it from that. Well, this is something I can use to do that. And I can also get it to do this, this, and this.

For a bit of an analogy: If you've got a toolbox of parts. And I think Postgres is really good at having lots and lots of tools in that box compared to different other platforms. And knowing which ones to use is both: you need to know what's in the box and also how to go and use that tool.

CLAIRE: Okay. So that's a perfect point to talk a little bit more about how you got involved in Postgres. So you mentioned that, that mailing list posts. But I imagine there's, there's more to the story than that.

How did you get involved with this toolbox of parts?

CHRIS: Yeah. So I think again, a lot of it comes back to that curiosity and having problems to solve and needing to go and solve them. So I remember there was, I was also quite lucky probably in that my first job that my peers who worked there had probably instilled quite good architectural processes. Before we started projects, we used to think about data modeling and application architecture and spend, say, a few days writing up a little bit of, "here's how we're going to approach this project" and that stuff.

And I think it's... to some extent the success of Agile has eroded it. Some of those activities, but too much that, well, if we're going to go and we need to go install this data in this place, then once you start breaking down what I need to do, then it's very easy to start seeing where I can go and use things.

So starting from that basis of, we want to store some data, but then the stuff evolves, you get more difficult problems. And I think it's also a case of... You have to try things and experiment and keep trying things. I think one of the big misconceptions is that you could become an expert overnight.

I don't think that's true. I don't think there's a point where you can ever say you're learning is finished or complete. Right. I think that's always one of the things that is fascinating, especially if you've had those few interactions in the community as well, which is, you go to Postgres conferences and there's people with knowledge of so many different parts of Postgres. And Postgres is probably a big enough code base that nobody can understand the whole thing in its entirety.

And so you get people who are experts in the planner, or how storage works, or that stuff. And so it's always that concept that, I can only ever be as... There's always going to be somebody more knowledgeable than me. There's always going to be somebody less knowledgeable than me.

So I was going to say, there's always somebody I can teach. And there's always somebody that I can learn from. And so elements of knowing that stuff, go and look around. As the problems evolve and you understand new ways to go and do them. And it's, it's that element of: if you don't keep practicing it routinely, you're never going to become an expert at it.

Very much like the analogies that are often used about learning a musical instrument or playing a musical instrument. And then you're just going to pick off from those starting points. So, I mean, yeah, I think my first interactions with the community were those mailing lists.

And I also at that similar time, I actually went to my first Postgres conference, which was PGDay.EU in Stuttgart in 2010. And that was eye opening. I remember my first Postgres talk I ever went to was Gianni Ciolli talking about functions and his entire talk walked through building a chess AI effectively in Postgres functions.

And the talk was much more of a way to introduce people to functions and the actual advantage is all the stats tracking that goes on under the hood. And I think to me, I was going to that event, it gave me so many things to go and do more research about, to go and think about. That really accelerated my starting point of getting into Postgres even deeper than I was.

And that was then probably around the time I left working there and moved on to another company where I actually came in as "the Postgres specialist." And that was interesting in that, how it all happened is funny in many ways. It's that concept of going from being a general developer where I'd always done a bit of everything.

So, whilst I was in the development team, I actually built all the servers and was the sysadmin for the servers we had. I did lots of the backend code. I even built bits of the front end, worked very closely with a designer.

So I've always been that person that just goes across the whole stack and just gets what the client needs done. And then it was a bit strange to go to a place and now you're the Postgres specialist, but... that was probably the same time that Greg Smith had produced the book on Postgres 9 performance, which was another key tool for me.

And I think one of the good things I really like about that book is it explains all the different parts of systems you need to understand to be able to tune and improve performance. And that can be... how stuff links together is probably easy to miss at times.

And it's actually everything, leveraging everything that's important.

CLAIRE: Wow. I'm still, you've piled so many things on the stack. We can go in so many different directions. I'm still stuck on the Gianni Ciolli talk in 2010. And when you talk about building chess functions in Postgres, to introduce people to functions, it just reminded me that you do this as well. A lot of the speakers at Postgres conferences, particularly when they're teaching something that is maybe more to beginners or newbies, they really make an effort to use fun examples—or make the topic more approachable, even if it's a very complex topic under the covers.

And so anyway, I can see how that might've hooked you.

CHRIS: Yeah, definitely. Right. And I think that's also, to be a good speaker, you have to make a talk memorable and entertaining and, to jump around a bit. The first ever talk I gave, the feedback there was that I "made a dull topic even duller".

And that was probably a bit of a changer in that, okay, I need to try and change my style here and actually think and invest a bit more in how you actually approach selling the content, and how you get people to understand it. If they don't feel engaged and entertained, then they're the worst talk to go to.

And yeah, I mean, Gianni was definitely like a really great example of that. Boriss is also really good at those kinds of style of talks. Like his talk on JSON from PGDay Nordic last year was such fun to listen to and like a really good way of getting people to remember the key points and. Gianni was probably only really trying to get across a couple of fairly simple-ish features in Postgres, but did it in such a fun way.

He'd also introduced you to different other avenues and things like that.

PINO: Chris, that must have been some pretty tough feedback to receive and, and fairly blunt. How did you take it? Did it make you wanna just jump right back in, try again with a new talk? Or did it set you back?

CHRIS: Yeah, I mean, that was obviously a bit later and that was after my 2017 talk and done a fair number of talks in the past.

And I think at that point I was probably mature enough to realize and accept the feedback criticism for what it was. As opposed to, I think it's very easy to just think, "Oh, I'm awful, I shouldn't keep trying that stuff".

I think if I would have one message to anybody who has done one talk or is thinking about doing talks: It is like tough at times and you just have to keep putting yourself forward. Especially just even getting selected, right. That's a hurdle in itself. And if you don't keep putting yourself forward, you'll never get it right. You've got to be in it to win, type of thing.

And yeah, it's really easy to give up and sometimes to have the motivation to keep going. There are definitely times where I've thought, "Oh, I don't really have anything interesting to say and stuff like that". I also tend to limit myself in my talks to like use cases, and practical things, and what I've done.

Which probably means I don't have quite as much of a repertoire as say other speakers. But that's my style and I feel much more comfortable doing that. Because I feel like it's a lot easier to be in complete control of the knowledge domain. And I think that's for me, especially to manage my nerves going on stage at times.

I'm not really somebody who can remember a script and stuff. So I just more have to need to use the slides to know, "this is the order to go", to talk and lay the bits out in the right order. I think also there's elements of like... I remember I did a unconference probably like 2012 ish, I think, and I hadn't really prepared.

I just thought, "Oh this is cool." I went along and then it was like, I'll pitch a talk about Postgres completely unprepared. And it was a complete disaster. And somebody afterwards said, a friend said, "yeah, you came across as a complete and that's a hyperactive idiot". And that probably knocked me back a little bit, but also also just made me realize that actually, if I'm going to do this, I just need to be a bit more prepared and need to plan stuff and need to rehearse.

And so I think it's more of a case of: take the feedback and use it to improve what you do, right? Like, you would writing code.

CLAIRE: You are not the only person to tell a story about how your first conference talk had problems, right? There are so many brilliant speakers today who talk about that 1st experience, that 2nd experience.

I still cringe when I think of my 1st training session that I led at Sybase of all places, just dating myself and I was teaching them things about SunOS. I don't even remember what, but they videotaped it. And when I saw the video afterwards and saw how I was distracting the audience, by the way I was moving around on stage in a really unnatural way, because I was so nervous—it just made me cringe.

And, I just wanted to crawl into a hole. I felt so bad. And I think the maturity with which you talk about how you have to keep trying, and you have to take that feedback and do more preparation and take it seriously in order to get better is really, really spot-on and anybody you look at that's good: it didn't just happen. They practiced.

CHRIS: Right. And I really can't express it, just rehearsing your talk beforehand is so important. Right. Especially if you get nervous, especially the first couple of times I did my IoT talk, which is the talk I've had most success with.

I probably rehearsed it for three or four days. When me and a friend did a talk at Postgres London, actually doing it [presenting a talk] with two people is even harder and requires a bit more rehearsal and and that stuff. But we just met up three or four times over the week beforehand and rehearse the talk.

And especially as I was trying to hit quite a tight timeslot for that one as well. And it just makes it so much easier though. If you've done the preparation and I must admit one of my concerns in, in PGDay Nordic this year was I was feeling a bit underprepared... but, actually it all went pretty well in the end.

CLAIRE: Oh, it was great. Okay. We've segued into talks. We'll, we'll come back to your start in Postgres and open source in just a minute. I just want to share something about your talk that you gave in Nordic. I think I have a link to the slides. Yeah, I'll pop the slides into the chat in just a second.

It was called Advantage Postgres. Yeah. So I did get a little distracted in the very beginning trying to think, is there a tennis connection to this? Is Chris a big tennis player? Like, where's he going? And but it was great because you shared a lot of your tips and knowledge across several different parts of Postgres, about things in the toolbox.

CHRIS: Definitely. Right. And that's what I wanted it to be. And I've tried to pitch the concept quite a few times and it was lucky. It got accepted this time around. And there's also a lot of the feedback I got from my IoT talk was that this is actually just a really good run through of different features to use.

So my original idea was, I can take a lot of the content from there and respin it, remodel it, and then add stuff in. And yeah, it was very much meant to be a walkthrough of lots of different tips and tricks I've used over the years. And actually like some of the feedback from the audience immediately after I came off stage, a couple of people.

[People's reactions were] like "that's a brain changer", right? Those things. And it's not necessarily at times that people don't know they exist. It's knowing that you should go to use them as well. I mean, I've worked with so many architects and stuff, I've worked with architects who even dislike people having foreign keys and things like that.

To some extent that just smacks of, they've not really written any code for a long time, but also it's like, there's so many powerful features and things you can do in Postgres... If you put the effort in to know they exist and think about them, you can actually leverage them to make your application much stronger and more performant and that can be a massive advantage. And that's the angle I wanted to go at, don't just treat the database through the eyes of an ORM, which is what a lot of people do. SQL has moved an awful lot since like 1992. And Marcus Winand's website, Modern SQL, is a great example of just that... And that's probably another good source I've learned stuff from over the years.

And I've been, I met Marcus, I think back in 2015 at PGConf.EU and chatted to him a bit. And he was talking about like his content and sites he'd been writing at that time. And so I went and read them and there's some really good information on there about all the different features of Postgres and or just of SQL in general, and really good pointers to which databases support what, and things like that.

And really great sources. I mean, that's some of those people do really good content and are very valuable for learning what you can do.

CLAIRE: So there are so many people who create all this different content, how does the fact that Postgres is open source play into that? How does the fact that Postgres is open source play into your work and your experience these last 18 years?

CHRIS: I guess there's two elements to that. I am fairly invested into open source as a political movement. So I do go out of my way to run Linux. I have been running Linux as my only desktop since I was 15 or 16. So there's that element of... I do deliberately try to only really use open source software. And I think people always find it strange that I really know nothing about Oracle—and that's pretty much entirely by choice.

But so there's that element that: it being open source is very important to me. It's that political and ethical side. But also being a curious person, it's a really great advantage to be able to "scratch your own itch" and understand how that black box works.

So an interesting example of that was we had a fairly big stored procedure that was processing a lot of deletes. And after three days it was still running and okay, this is a bit weird. And so you start digging into things. And then I dug through the source code to find the one comment in the source code that said "we don't really expect anybody to hit this condition" therefore we're using a singly linked list and, and it's like, ah, okay. So maybe I should try not to hit that condition in that particular instance. And so for me, that has been very interesting and useful over the years... also Linux, I've dug through Linux source code at times.

And I remember investigating some problems with trim and XFS on a NetApp and things, the ability to look into the code and actually understand what's going on was so valuable, especially to be able to prove to other people and other consultants... The one thing people can't argue about is when you show them the line of code. But yeah I find the fact that Postgres is open source really advantageous for being able to increase your own understanding of it, because you can just go and read the planner code and read the executor code. You can also just dig through and understand some of these little quirks and things, which you can't do in any other commercial setting

CLAIRE: Yeah, that ability to just look in and understand. What's interesting about what you just said, when you were describing the stored procedure that was still running after 3 days is that you made the comment. "That's a bit weird". I'm going to dig into that. That those are almost not quite the exact words, not the exact words, but very similar to what Andres Freund told me the other day.

About his investigation to the xz backdoor, right? He's like, huh that's weird. That shouldn't be happening. And then he just dug and he dug and he dug. And anyway, I am so thankful for his discovery.

CHRIS: Yeah, I mean, it's definitely a really interesting. And it's probably not really the first time this type of attack has been tried on the community.

And I think also it's a really good demonstrator of what's often termed Linus's law that "with enough eyes all bugs are shallow" type stuff. And, and I think the bigger discussion point here is probably more that were the right people looking and I think probably not is the real answer.

Yeah. And yes, Andres has pointed out on Mastodon, it took a lot of coincidences for [him] to spot it. But also if there was anybody tenacious and curious enough to go and dig into it and find it and then unwrap it all, it was probably him. And yeah, it's one of those things where to some extent I think it's really easy for people to say it's luck that we spotted it.

I mean, look at the number of backdoors that have been in say Cisco or Juniper for years and years that nobody knew about. And, I think actually the key thing here is: bits of open source have actually worked how they're meant to.

CLAIRE: Yeah. I think he's been overwhelmed by the response.

There's just so much appreciation and recognition and I don't know. I think everybody in the Postgres community is jazzed that a Postgres person who was investigating this 500 millisecond latency regression was the one to discover this.

CHRIS: Yeah, I mean, I loved somebody's take, which was It's more interesting to see that Postgres devs are really serious about performance.

CLAIRE: They are, and somebody else said, okay, I better make sure I don't slow down Postgres in any way, otherwise Andres is coming to get me. So it's been interesting. Okay, let's get back to you. Because obviously the Andres stuff is being covered in lots of other places and even podcasts.

PINO: I'll chime in about something Chris said, or I really admire. I didn't succeed as an engineer. I'm now an engineering manager, but I never succeeded in really boldly attacking all the layers, in investigating all the layers. It takes a certain amount of of confidence, right? To go through layers of code.

Huge code bases... I guess going through a debugger, that can help because at least you have a path to follow, but sort of putting it all together. How do you encourage or train or... what advice do you have for for developers about having that curiosity and that confidence about going and looking in all layers of the stack code bases that you didn't develop yourself, that you're not actively working on possibly.

CHRIS: Indeed. I guess, well, there's two elements to it, right? I think you have to have the passion and curiosity to go and do that. And part of me would also say, if you're really not that interested in looking at it, then you're probably never going to become an expert in it. And maybe go and focus on something you do actually find genuinely interesting to you.

And everybody's slightly different in that regard. But I think also it's really easy to just stay inside your little perceived box and not understand like how the layer below you works. And one of the things I do find a bit concerning is, with a lot of modern software architectures, we have so many levels of abstraction now that: Is it feasible for somebody to really dig as much as they once could? And I'm not sure if the answer is yes anymore. And I'm not sure if that's a good thing.

But I think the first time I went and dug through some kernel code, I'm not a C expert. And that's probably one of the reasons I'm not really a code contributor to Postgres... my C skills are probably a bit lacking and they're much more focused on embedded hardware than they are on the server software. But most code is fairly readable. And actually, one of the things I think is really good about the Postgres code base is it's a really good shining example of well-written code. A lot of it's well commented, it's actually quite easy to find yourself your way around.

It's got a very good strong internal architecture. And I think bits of that come back to... In my electronics background, the first thing we always do when we're designing a circuit is what you call a block diagram, right? I know I need a power supply.

I know I need this, I know I need that. And that's how I try to approach software is draw out those black box little subsystems I need and then know what's going to talk to what. And then I can expand my knowledge on under each of each of them when I need to.

And so, if you think about things like that, then it's a, well, I've got a database is going to call and put stuff in a file, right? Okay, well, now I've got a very simple thing of, well, how does the file system work and then go and dig through that and. In terms of Linux knowledge, there's a great book by somebody called Robert Love which just goes through really simply expanding out on all of the fundamentals of the kernel.

Probably one of the best written books I've ever come across of explaining how Linux works. What's, what's it called again? It's something like Linux Explained or something like that, I think, or Understanding Linux. I shall double check my bookshelves later on.

CLAIRE: Okay, okay. And, and what's the author's name again?

CHRIS: A guy called Robert Love. He used to work at, I think he works at Google these days, but back then he worked for Novell after they acquired SUSE.

PINO: Cool. Maybe I'll ask, I don't want to get into a whole segue about AI, but it's relevant here in that I wonder if it makes this investigation more accessible with Copilot helping to understand code bases.

Do you have any thoughts on that? Have you used AI to understand, to help your debugging, or to help your understanding of code bases?

CHRIS: Yeah, it's interesting. I must admit, I'm a bit of a skeptic on it at times. And we have been using it recently on one project to summarize telephone transcripts.

And I've been quite surprised at how good it is for that use case. In terms of looking through code. Something that's able to chain and look up this function, this is calling this function, [and] jump me to that source code. It's probably the thing I really value the most and some languages that's a lot harder.

And a good text editor is great for that stuff. I mean, being a Java person, for me, Eclipse was always incredible... that stuff, just press F3 and you jump to the source of what you're calling. And yeah, I've not really tried Copilot for some of that stuff.

I think my concern would be if you ask it to try and summarize things, whether it's going to then make too much of a decision for you, where it's going to try to explain things and.. One of the things I have seen a bit too much is hallucinations. My boss quite likes using Gemini or whatever it is and he goes, "Oh, does Postgres have a way to do this?" And then it's like, Oh, I'll ask Gemini. And then I spend the next half an hour explaining to him that it's just hallucinated the wrong answer to you. So I think there's definitely some improvements all these tools need.

And I think if they were better at citing their sources, then potentially I might value them a bit more.

PINO: So we might have to wait a little bit longer, but yeah, thanks. Thanks for your answer.

CLAIRE: I think what worries me is someone like you, Chris, can see that perhaps something is off in one of these answers from an AI system, because you have become more expert. But it might seem very plausible to someone else. So recognizing hallucinations is challenging,

PINO: I think I don't see Chris on stage anymore. He must have gotten disconnected.

CLAIRE: Okay. Well, we, we will wait for him to come back. In the meantime, those of you who are on the chat, if you want to pop in questions that Pino or I can talk about. Oh, Rob, that's perfect. Now is a good time to remind people about the POSETTE CFP. So those of you who listened to this podcast live here today, as well as we're going to publish it in a couple of days on Friday. And so there'll be a 2 and a half day window from when it first gets published from Friday, midday Pacific time until Sunday night at 11:59pm PDT, Pacific Daylight Time, and that's Sunday, April 7th, the CFP, the call for proposals. We're going to be still open, and so you'll have a chance to submit talk proposals.

So POSETTE: An Event for Postgres, is a third annual virtual event which is organized by the team here at Microsoft. But last year, I think more than 60% of the speakers were from outside Microsoft. Many people from within the Postgres community, people who are contributors, community members as well as, Azure Database for PostgreSQL customers and Citus open source users...

People from a whole bunch of different circles all came together and had these wonderful virtual talks recorded. So the CFP is open and I encourage anyone, even first time speakers, as well as super experienced, and everyone in between to submit. What have I missed? I think Chris is back.

CHRIS: I think Discord decided to have a moment.

CLAIRE: Well, we decided to talk about the CFP for POSETTE while you were gone because we're in that hockey stick of the last couple of days that the Call for talk Proposals is open.

And people are curious about whether you submitted a talk proposal to POSETTE. Sometimes people don't want to reveal that until after they've been accepted or rejected.

CHRIS: I have submitted two and I have two more I want to submit as well.

CLAIRE: Awesome. Yeah, there's a limit of four. Yes. Got it. Well, I think that would be great.

I know the top selection team would love to consider your proposals, Chris, because I'm on it. So people also had questions about your lightning talk that you just gave at pgDay Paris, which was titled "Electric Elephants". I am literally holding one in my hands and I'm turning it on right now, because it's just so cool. Let's just do a quick segue on that.

CHRIS: Oh yeah. So I guess for the people who are listening, and listening later, I basically designed some light-up LED badges in the shape of an elephant which I've given a few out to people at both PGDay UK last year and various other events.

And I did a very brief lightning talk on where they came from, why I did it and how I went about building them and that stuff. And yeah, they were very much a bit of a because you can type thing inspired by a cat design I did based off of an art deco glass pendant.

And I thought, the color scheme worked well with PCBs and I can do some lights on it and then it all spiraled a little bit out of that into then designing some in the shape of an elephant for my love of Postgres really. And then, yeah, all designed in, KiCad, so it's all open source.

And then the software is all Arduino, and it actually runs a little tiny state machine inside, so you can actually program the patterns effectively. And then I even went as far as building a full online emulator and editor.

CLAIRE: It was really fun to watch. Lightning talks are just such an opportunity to be creative.

You only get five minutes and then you get kicked off the stage. So you have to really hone in and focus on what, what can I share in five minutes, that people in the audience will enjoy or will benefit from? And yours was definitely in the enjoy category.

CHRIS: I think it's also a great way to get slightly different content.

And I think especially some of the events it can... it is nice to see the other random bits going on in the community and stuff. So I thought it was a really great opportunity and I thought it was good of the organizers for picking some slightly varied and slightly brave topic titles as well.

I thought all the lightning talks were really good and I thought it was a great way to inject some energy after lunch. And I definitely would try and persuade us to do it at PGDay UK this year and I think we're also talking about the PGConf EU potentially having two lightning slots And actually having a call for papers for it.

So I think that would be some cool steps forward and I think they're a very interesting and powerful type of talk and probably not enough of them get done at times.

CLAIRE: Yeah, and I think when the, the lightning talk CFP is a piece of paper that people have to rush to during the conference and they don't know if they're going to make it or not.

So, I think there's just so many people who don't prepare a talk because there's no guarantee that they're going to get the slot. And so you end up with a very different set of speakers. So I loved having the CFP in advance. So people could submit, they could know in advance if they're accepted, they could plan their travel accordingly, right?

Because some people can only get the budget to go to a conference if they... Obviously, a lot of attendees go to learn, but some people are in constrained economic environments and it helps them get their budget if they have landed any speaking slot. So, okay... Well thank you again for creating the electric elephants.

I dropped the link to the lightning talks in the chat to people want to go check it out.

CHRIS: Yeah. I mean there is some more information on my blog as well.

CLAIRE: Awesome. Yeah. I think from the schedule, there's a link to your slides, right? Yep. Okay. I'll get that in there too.

All right. So, when you disappeared, I was asking whether you want to talk about your learning style. You had told me that you are slow reader and obviously that has not inhibited your ability to learn.

CHRIS: Yeah, indeed. So I guess one of the key things is, I'm dyslexic, so, reading has never really been something enjoyable for me is probably the best way to describe it for people.

So, I literally have read five novels in my life. And trying to read a book from cover to cover is just a Herculean task. So, that's very much directed how I consume information. And that's probably where I said I found reading magazines a lot easier.

Or books that I can dip in and out of so, I tend to go and read books. It's specific chapters for specific topics and stuff. And and that's probably where I can consume probably a lot more stuff from, say, blog posts or, just going and reading certain pages of manuals and things.

And that's also probably where learning from peers, and talking with peers, and learning a lot more verbally has probably been how I wanted to choose to consume content. So that was probably one of the great things about why I got so much value from going to conferences... because that chance to speak to people who are the experts in that subject or to go and listen to that distilled information that then points you in the direction to go and do the painful research is very valuable to me.

CLAIRE: I know you also mentioned user groups before.

You are pretty active in user groups, particularly in the UK. Is that right? Okay.

CHRIS: Yeah. So I'm definitely on the Linux user group side. I've been a member of Wolverhampton Linux User Group since 2008. And back in the day, they used to do a podcast called Linux, Linux User Group Radio (LUG Radio), which even had live shows and everything, and then spun out to be Oggcamp.

And that was always quite good as well. I mean, especially back in that era, we used to do probably monthly or quarterly talks and stuff. So. I definitely remember doing a talk there about DNS and things, but it was also just a really great chance to go and meet people and talk about things and, and that social side.

And also that social style of learning where, we just used to meet up in the pub and the ability to sit and chat with somebody who'd been using Linux from pretty much say the mid-nineties and using it professionally, [who] always had something to share and teach and that you could learn from. And then of course to do that to the new people who join, and sometimes, the ability to talk through a problem with different people, to get different people's perspective on things was valuable and interesting.

And Postgres London used to do some meetup groups, and it'd be nice to get it going again. Some of those sessions were much more, rather than having talks all the time, we actually just had round table discussions around this particular starting point and go from there.

And there were definitely some interesting topics and discussions where. People had very different viewpoints and sometimes those different opinions give you different ways to perceive problems, and understand them, and learn in that way as well.

CLAIRE: What what I love is that, with your dyslexia and the fact that reading isn't reading a book cover to cover isn't the effective way for you to consume information, is you've just found all these other ways.

To learn, like you said, from peers at conferences, by doing, by being curious, and poking at things, and fiddling. And I think it's a great story for anybody who has any obstacle in their way and their process of learning, or maybe they can't take the traditional approach.

You're just proof of that. You don't need to take the traditional book learning approach and that maybe it's not even traditional. Maybe I shouldn't even call it that, right?

CHRIS: Yeah. I mean, I'm almost at the viewpoint that there's probably enough different ways of how people's minds work that there's no real concept of like what is normal, right?

But yeah, I think the key thing is you have to find the style that works for you and I've never been the person that could go and sit in a library. I find the most productive place for me is to be in the coffee shop, where there's a bit more noise going on. And it's weird, I can focus and concentrate much more in the coffee shop than I can in a library... you just have to find what works for you and don't be afraid to do and try that.

And I've always been [drawn to] the more practical side of engineering as well. So I've always liked hacking something together, building something. And if you have a little problem to scratch an itch, you can learn so much more by having something that you're interested in doing and want to go and build than you could reading a book.

To be honest, that's what one of my opinions would be. If you have an app that you want to build, just go and build it. Because you will learn so much doing that, that you couldn't have learned from a book. And that's where probably an awful lot of my becoming an expert has actually come much more from... by doing things and trying things and also being open to admit, "yeah, that didn't quite work out, I probably shouldn't have done it that way. Next time I'm going to do something slightly different".

But if you don't keep practicing and don't keep doing that stuff, then I don't think you can ever, you can never become an expert by just reading something and having that theoretical knowledge, especially now.

CLAIRE: We've bopped back and forth between building your Postgres expertise. And and how you became more and more expert and your involvement in conferences, user groups, events. But at some point, you, you pivoted from just being an attendee and participant to being a speaker, and then you pivoted to helping to organize Postgres events in particular.

And I'm curious how that happened. I know there's a story.

CHRIS: Yeah. So I guess submitting talks to Postgres was, was something that was sort of natural. Cause I'd done it quite a few times in the Linux groups I was in. So it's always been... it'd be quite nice to go and speak at say PGDay or PGConf.

I must admit bits of it were, "Oh, well, I'll just submit an abstract, see what happens". And then I was quite surprised to get accepted. And then it was like, okay, it's become a bit more real. And [after] getting that first talk accepted, it's probably a lot easier to try and think you can do it the second time around.

And I think to be fair, one of those hurdles was that mental thing of, well, I don't have anything interesting to say. And, I think it was really easy to fall into that mindset of, Oh, well, I'm not a developer or a committer for Postgres, therefore I can't be the most expert—or, I can't know that thing in huge amounts of detail.

And I think it was, it was definitely Simon Riggs. He told me that "look, even I have to go and read the manual page to know how to use that bit of SQL" or something like that. And it's very powerful to have somebody I admired greatly, and had probably known for a few years at that point through going to events and post West London stuff to say that it's actually perfectly fine. Nobody's going to be an expert in everything and there's no weakness in admitting what you don't know. That was definitely a big hurdle to get over to get into speaking a bit more, because to be honest going and speaking at Postgres events can feel a bit intimidating at times. You know I've been heckled by say Dave Cramer and things like that.. And there's these people in the audience who you know. I think I had Tom Lane in the audience one time for one of my talks and this is somebody I admire greatly from all of his replies on the list.

And then getting over the, "well, what if he asks a question I don't know how to answer?". And actually, it's perfectly fine to say, I don't know that. It's always that supportive environment to some extent of, well, if you don't know it, somebody else in that room probably does.

So that was probably a big mental thing to get over, and to also know that there is help and support out there in terms of just the friendliness of the community and then segueing into getting more involved, organizing. Simon asked me to be on the talk selection committee for Postgres London the first year after COVID.

So I'd spoken the previous year at the virtual event and also in the physical event in 2019. And it was him that who invited me to say, would you help out on the talk selection? And I was, yes, of course. And it was one of those things, it was actually quite powerful being asked to be involved.

And that was definitely then a segue to try and get a bit more involved in, in other things. And when Simon announced he was stepping back from the community and handing over Postgres London to Dave back in Berlin in 2022, I afterwards went up and and said I'd be very much interested in trying to help out and get Postgres London going again and get PGDay UK going again.

And it grew from there a little bit. And then I've got more and more involved. I spent this weekend building the website for PGDay UK this year. And yeah, so it's also one of those things where sometimes you forget with open source communities, you have to just step up and offer to help rather than be asked to help.

And that was probably a little mental thing that I'm probably only just getting to understand.

CLAIRE: So in my brain, I'm realizing that you are one of many, many examples of people that Simon Riggs touched, whose path in Postgres was influenced by his leadership. And I know there's so many people that we've heard from, all the places online and on calls, who are still still struggling to process, what happened last week with his passing. But I think it's wonderful that he asked you to take on these roles and you're continuing to do it.

CHRIS: Yeah, and I remember especially, was it 2021? The first physical Postgres London then, PGDay UK, and Simon was went to me and Russell and said "I'm going to leave at halftime, halfway through the day, because we're going to an Elton John concert. "ou'll be fine. Just get on with it." And then, to have the trust in the people he'd got to help out that we could just finish and run the rest of the day was, was quite powerful. And probably a very good example of his leadership.

And yeah, sadly [he'll] be sorely, sorely missed. And yeah. We [Simon and I] only really met at events over the years, but he was definitely, I think a very great technical leader of the project and definitely responsible for an awful lot of the things that make Postgres what it is today, to be honest.

And also just, I think one of the things I always found really impressive was [Simon] had a very long plan and a vision. And I don't think there's that many good leaders who know what they want to put this into release, and they've got a strategy of where they're going. And he was very good at that.

CLAIRE: Well, speaking of a long plan and a vision his keynote talk, Simon Riggs's keynote talk at PGConf.EU last December, which was in Prague was titled The Next 20 Years. Right? So even though he was retired at that point and was no longer working at EDB and 2ndQuadrant, he made the effort to come, to put in the prep, to give that keynote.

And I thought it was... a lot of people had positive things to say about it, about the vision and the inspiration. So I'll make sure we drop that link into the chat as well. All right. So back to you, Chris, before, before we wrap there's a few more things we really wanted to cover.

Are there any other resources, like conferences, docs, extensions, books, website, or things that you want to give a shout out to, that you think would be useful to other people who are trying to skill up in Postgres?

CHRIS: Yeah, so I think I've already mentioned Modern SQL. I think the other one that's really very good is Dimitri Fontaine's The Art of PostgreSQL.

That's an extremely good book and good resource. Also if you want to see to some extent the art of the possible, Vik Fearing's Advent of Code stuff is, it's always fun when he's doing that. And, a good demonstrator of [what] you can actually solve an awful lot with just SQL.

Also Planet PostgreSQL. Just go and find some Postgres people, follow them in whatever social media you use, and it's a great way to go and learn about different tips and things and to go and find out a general buzz of what's going on.

Definitely that stuff has been fairly advantageous for me about, when somebody puts a blog post about UUIDs and stuff that and, having those interesting opinions at times is actually then a good driver for you to go and test your internal understanding and also go and maybe learn a bit more.

Also I think to be honest, the Postgres docs get a bit underrated, right? They're some of the best documentation for open source projects out there. There's so much detail in there about low level stuff about how to use this SQL, lots of good examples. And at times, if you just need to know a feature exists and then you can go and find the good documentation, [it's] definitely plus one, it's not an RTFM, right?

It's a, it's a, use it and dip in and out of it as you need to and things like that.

CLAIRE: Well, and I know that. It's not necessarily easy to contribute to the docs from a procedural standpoint. Yeah, I think that there's huge appreciation. If you see things that Are wrong or unclear or ambiguous or do need fixing in the docs.

People love it when you submit you can do it on any docs page, right? When you submit a bug basically. And they of course love contributions from anybody when it comes to docs, you don't have to be a Postgres developer to contribute to making the docs better.

CHRIS: Definitely right. And it's probably something I should do a bit more of now and then.

But yeah, I mean. I do think, and also there's documentation at so many different levels, right? Because you've got the docs of how to use this SQL. You've got the docs of then how that works under the hood. And then the docs of how to administer it. And I think maybe at times, people just need to think a little bit about what level they need to go and read and things in the actual docs.

CLAIRE: So Elizabeth Christensen, I actually noticed her blog post from Planet Postgres because I follow Planet Postgres on Twitter. I'm on all the platforms, right? Mastodon, Twitter, Threads, Discord, Telegram, blah, blah, blah.

And she just published a blog post called Contributing to Postgres 101, a beginner's experience. And she walked through something's missing from the docs, a patch idea, [asking], how do I help fix this? And I just thought it was a very positive story and one that shines the light on, how would you do this if you wanted to? So I'll drop that link in too.

Did you see it? Do you know what I'm talking about?

CHRIS: No, I didn't actually see that one, but definitely be interested.

CLAIRE: Cool. Yeah. I dropped in the link. All right. Well, before, before we wrap are there any final thoughts. I mean, we didn't really get to dive into how you use analogies to help developers and users understand things about Postgres.

Maybe someone has to go and attend one of your talks to benefit from your analogies.

CHRIS: Yeah, I'm never sure if I've been a great one for analogies either. Right. And also I think half the time you just, if you make them up, you make them up on the spot to some extent. But yeah.

CLAIRE: Okay. So I really, really appreciate you joining us today, Chris.

This has been an awesome conversation. Pino, did you have any final questions before we wrap?

PINO: Oh, nothing. This has been a fascinating conversation.

CLAIRE: Well, then this is a big thank you to Chris for joining the next episode is going to be recorded live on Wednesday, May 1st at 10:00AM PDT I think we're all done with our time changes across the planet.

Now the guest will be Michael Christofides of pgMustard. And if you can go ahead and mark your calendar aka.ms/PathToCitusCon-Ep15-cal. You can always get to past episodes of this podcast and get links to the podcast platforms at aka.ms/PathToCitusCon, all one word.

Transcripts are included on the episode pages for each and every episode on Transistor too. Now, before we leave today, I have a big thank you that I also need to communicate to Pino. Pino has been a host of Path To Citus Con since the very beginning, which was a year ago. And initially this podcast was just going to be a two episode pre-event for last year's Citus Con.

And in the beginning we thought, well, maybe we'll run an experiment and we'll continue the podcast recordings on Discord for a few more episodes after the Citus Con virtual event is behind us. But here we are a year later. Path To Citus Con is thriving. It has less and less of a connection to the original Citus Con event.

And it's really just a great podcast for, for people who care about Postgres, I think. And it's been really wonderful to prepare and collaborate with you, Pino. And I appreciate all of our time together in the last year. I love your questions. I love your curiosity and even the timber of your voice. So, thank you.

And we're going to miss you as a co host.

PINO: Well, thank you, Claire, so much. I've learned so much from you and enjoyed listening to you as we co-host the podcast episodes. I definitely stepped out of my comfort zone in joining the podcast for the first two episodes and then for the year.

And I looked back at the year and what a year it's been. We've had 14 episodes with 25 guests, if my count is correct. And just an awesome set of guests and people from diverse backgrounds located all over the world and fascinating stories.

And I really love this people aspect of the podcast and delving into how people started and as developers, as technologists, as as Postgres community members and I, and that's what I'll take away from it that really, and really cherish. And I look forward to being a listener on the podcast moving forward. Where, and that's much more my comfort zone than being on the mic. But I want to thank you and the production team Aaron, Ari, previously Carol, just for a great collaboration.

It's been, it was fun, all the brainstorming and the guests and the audience that make the live show so fun on Discord with side conversations and all the comments and links. And again, yeah, thanks to everyone. It's been a wonderful experience.

CLAIRE: Thank you, Pino. So, before we leave, we also want to ask those of you who are still listening that if you've enjoyed this podcast, please give it a rating and please give it a review on your favorite podcast platform. Ratings and reviews absolutely help other people like you discover this show. And a big thank you to everybody on the chat who's been here live today and participating in the conversation.

Especially when Chris disappeared for a few, a few minutes there. It was great to get your ideas about what we should chat about. So that's it. It's a wrap. Thank you. See you next month.

CHRIS: Thank you.

PINO: Thanks everyone.