WEBVTT 1 00:00:14.519 --> 00:00:19.000 What's going on? Everybody. Welcome to another episode of Adventures and dev Ops. 2 00:00:19.039 --> 00:00:22.719 I'm your host Will Button and joining me today. This is going to 3 00:00:22.760 --> 00:00:27.960 be exciting. I have the founder of pg Analyze and a member of the 4 00:00:28.000 --> 00:00:32.079 founding team at product ND. I've got Lucas Fiddle. Welcome, Lucas, 5 00:00:32.719 --> 00:00:35.560 thank you, happy to be here right on. I'm excited to have you. 6 00:00:35.719 --> 00:00:43.719 And this follows on nicely to an episode we had two episodes ago talking 7 00:00:43.840 --> 00:00:49.920 about the role of DBAs in our environment, you know, with our with 8 00:00:49.960 --> 00:00:53.439 the movement that's happened over the last decade. You know, whenever I started, 9 00:00:53.520 --> 00:00:58.799 DBA was like the premier role to have in technology. You know, 10 00:00:58.880 --> 00:01:03.840 being a database administry was like the ultimate role because you could just you could 11 00:01:03.840 --> 00:01:07.480 just say no and shut everyone down, and you know, the company was 12 00:01:07.519 --> 00:01:11.200 almost powerless to do anything about it. Not that that was your goal, 13 00:01:11.319 --> 00:01:15.120 but like that was the prestige that the DBA had. And these days we 14 00:01:15.239 --> 00:01:22.480 just don't see as many DBAs around, but those tasks that the DBAs do 15 00:01:22.799 --> 00:01:26.079 still exists, and so I'm interested to hear your perspective on that. But 16 00:01:26.319 --> 00:01:30.640 before we jump into that, give us a little bit about your background. 17 00:01:30.719 --> 00:01:33.719 How you got to this point. Sure, yeah, and you know, 18 00:01:34.640 --> 00:01:37.400 I'll try to relate this to also's Postcrest, which is the database I care 19 00:01:37.439 --> 00:01:42.959 a lot about. So over the years, you know, I eventually started 20 00:01:42.959 --> 00:01:47.560 out in those six dozen and seven putting servers in racks. But back when 21 00:01:47.560 --> 00:01:49.920 we still had racks. You know, still do or have racks. It's 22 00:01:49.959 --> 00:01:53.480 just you don't think about them anymore geological concept more than the physical figure think 23 00:01:53.519 --> 00:01:57.359 about And so you know pretty much you know, early like right after that, 24 00:01:57.400 --> 00:02:00.599 you know, kind of the first job I had, I you know, 25 00:02:00.640 --> 00:02:02.000 kind of started a startup with some friends of mine and Postcress was a 26 00:02:02.079 --> 00:02:06.640 database of choice, right, and so you know back then, you know, 27 00:02:06.680 --> 00:02:09.080 we kind of just had everything stort in our postgress and as you know, 28 00:02:09.280 --> 00:02:13.080 my personal career went on, I kept, you know, seeing Postcress 29 00:02:13.080 --> 00:02:15.960 over the years, right, and postcus is an old database, like it's 30 00:02:15.960 --> 00:02:17.360 not as old as I am, but it's close to it. Right, 31 00:02:17.520 --> 00:02:23.520 So the you know, like they turned I think twenty seven years last year 32 00:02:23.919 --> 00:02:30.240 post was it not life? So uh, the really the story here, 33 00:02:30.280 --> 00:02:34.800 right is that I think what I've seen over the years in my career, 34 00:02:34.879 --> 00:02:38.080 right, is like so like product hunt for example, use posts my database 35 00:02:38.159 --> 00:02:42.800 right like product the community. The database was you know, reasonable, not 36 00:02:42.840 --> 00:02:45.800 the biggest database, but it just worked right like you just had the system 37 00:02:45.840 --> 00:02:50.719 of record and that was Postgress. And then after that I joined a company 38 00:02:50.719 --> 00:02:53.120 called side of Data. Inside of Data is essentially a way to scale out 39 00:02:53.159 --> 00:02:57.280 Postgress, and that ended up being a quiet Microsoft. So you know, 40 00:02:57.319 --> 00:03:00.439 I had some fun in the corporate world for a little bit. And then 41 00:03:00.680 --> 00:03:04.680 you know, really what this led me to is where wearing math currently, 42 00:03:05.400 --> 00:03:07.800 which is a company called pg Analyze. And so pg Analyze is a small 43 00:03:07.800 --> 00:03:14.080 startup, bootstrapped very intentionally, so no VC funding. And really the idea 44 00:03:14.159 --> 00:03:16.479 is that we want to make post press work better. Right posts performance in 45 00:03:16.479 --> 00:03:23.039 particular work better for the application engineers, the BBAs the data platform engineers help 46 00:03:23.120 --> 00:03:27.560 you optimize slow careers better. I've actually run this as a side project before, 47 00:03:27.800 --> 00:03:30.199 you know, kind of I went full time. So I actually started 48 00:03:30.360 --> 00:03:34.919 technically like almost eleven years ago. Wow, but you know, only I 49 00:03:34.919 --> 00:03:37.800 would say the last four or five years has been really a serious project. 50 00:03:37.840 --> 00:03:39.560 Right before then, it was more of a this was, you know, 51 00:03:39.879 --> 00:03:43.159 solving a problem. Some people are paying for it, but really, you 52 00:03:43.159 --> 00:03:45.479 know, as a business. It's really been you know, the last couple 53 00:03:45.520 --> 00:03:49.439 of years where it has taken off and we've really seen great success right on, 54 00:03:49.719 --> 00:03:52.680 So you kind of it's it's one of those sounds like it's one of 55 00:03:52.719 --> 00:03:58.759 those stories where you had a specific problem personally and you built this tool to 56 00:03:58.840 --> 00:04:01.919 solve it and then realized, hey, other people kind of have the same 57 00:04:01.960 --> 00:04:05.199 problem, that's right. Yeah, And I actually so I had a friend 58 00:04:05.240 --> 00:04:09.319 who he was involved early on with the project but is no longer. But 59 00:04:10.039 --> 00:04:13.840 I had a friend who was essentially my go to book posters person. Right, 60 00:04:13.840 --> 00:04:15.919 So if you asked me ten years ago, I probably wouldn't have been 61 00:04:15.919 --> 00:04:18.439 that smart about poscasts asiety these days. Definitely not the smartest. There's definitely 62 00:04:18.439 --> 00:04:23.560 smarter people out there. But I learned or two. But you know, 63 00:04:23.600 --> 00:04:26.000 back then, essentially he was a person I would ask, you know, 64 00:04:26.000 --> 00:04:28.560 how to optimize this query? How do I know set this thing up so 65 00:04:28.639 --> 00:04:30.959 it works well? How do I direct the replication? And so really, 66 00:04:31.000 --> 00:04:35.360 in part of scratching my own interest inially was this is a person that's great, 67 00:04:35.480 --> 00:04:40.000 but as there's some tasks that just don't seem necessary for a person to 68 00:04:40.079 --> 00:04:45.240 do manually, right, for sure. Yeah, and I think that's one 69 00:04:45.279 --> 00:04:47.879 of the things I've encountered as well as like I have in my own network, 70 00:04:48.279 --> 00:04:51.680 like, oh, this dude is my go to guy for that. 71 00:04:53.439 --> 00:04:58.160 But you know, it's a personal relationship, you know, and I'm always 72 00:04:58.680 --> 00:05:02.600 concerned with, you know, making sure that that relationship goes two way and 73 00:05:02.600 --> 00:05:09.079 that I'm just not beating these people up with questions, you know. So 74 00:05:09.279 --> 00:05:15.199 yeah, I see the need there to build that. So what what were 75 00:05:15.199 --> 00:05:21.000 some of the like big things that you were trying to accomplish with postgress or 76 00:05:21.000 --> 00:05:25.199 doing cogrit postgress or how did you even know that these were things that you 77 00:05:25.279 --> 00:05:29.519 needed to be worried about? I mean, the simplest thing is just a 78 00:05:29.560 --> 00:05:33.319 slow query, right, which I would say basically everybody who runs a postcres 79 00:05:33.399 --> 00:05:35.839 data base we went to slow query at some point. And this is not 80 00:05:36.000 --> 00:05:39.319 you know, just postgress, right, it's just any database. Really, 81 00:05:40.000 --> 00:05:43.279 Queries are a thing, right, Like that's your basic unit of work essentially, 82 00:05:43.720 --> 00:05:47.600 And so I think the most fundamental thing is the database doesn't behave as 83 00:05:47.600 --> 00:05:49.800 I expected to write, Like, it's not as fast as I expected to 84 00:05:49.879 --> 00:05:54.279 it's returning less data than I expected to, like, whatever it's happening. 85 00:05:55.199 --> 00:06:00.560 And so really I think that was the most fundamental thing is understanding which careers 86 00:06:00.600 --> 00:06:03.360 are slow. Right. Sometimes you have visibility problem because sometimes on the application 87 00:06:03.439 --> 00:06:06.399 side, you're actually calling a function like in your orem, you're not really 88 00:06:06.399 --> 00:06:10.199 thinking of the database as queries, right, You're not actually running SEQL. 89 00:06:11.040 --> 00:06:14.680 Sometimes it's just a visibility problem. But then once you once you know which 90 00:06:14.759 --> 00:06:16.279 query is slow, there's a question of you know, why is it slow? 91 00:06:16.360 --> 00:06:18.959 Right? How do I how do I go from knowing it slow that 92 00:06:18.959 --> 00:06:24.120 it's kind of this matching box of activity to you know, actually the database 93 00:06:24.240 --> 00:06:26.920 is doing just index scan, it's doing a sequential scan, it's doing this 94 00:06:27.040 --> 00:06:30.279 joint and maybe there's a better way to join things, right, So there's 95 00:06:30.319 --> 00:06:33.639 there's different choices of how the database implements what you tell it to do. 96 00:06:34.600 --> 00:06:39.240 And so this is I think really the most fundamental thing that I've seen myself 97 00:06:39.759 --> 00:06:44.560 need to know about databases is you know why things are slow and can I 98 00:06:44.600 --> 00:06:46.920 do something to improve them? And then you know, the more you have 99 00:06:46.959 --> 00:06:49.920 an expert at hand, Really, what the expert I think can do is 100 00:06:50.720 --> 00:06:55.279 help you understand which action to take right, and the action might be something 101 00:06:55.360 --> 00:07:00.439 like rewrite the query kind of get database to a different querer plan. There's 102 00:07:00.480 --> 00:07:03.920 like different ways to influence what's going on. But understanding is you have a 103 00:07:04.160 --> 00:07:06.759 slow queer problem in the first place. I think that's really the most fundamental 104 00:07:06.800 --> 00:07:11.040 thing to start with for sure. Yeah, and I'm glad you brought up 105 00:07:11.040 --> 00:07:15.319 o rms because they are, like I think anymore, that's like the default 106 00:07:15.879 --> 00:07:20.120 and interaction for a lot of engineers with the databases just through the o RM, 107 00:07:20.959 --> 00:07:26.079 and you don't see the queries that they create a lot of times. 108 00:07:26.120 --> 00:07:31.920 And I've seen quite a few instances where when the database performance slows, the 109 00:07:31.959 --> 00:07:38.079 first response is always to increase the size of the database server. And then 110 00:07:38.839 --> 00:07:41.720 and then you get that that bill, you know, you get the AWS 111 00:07:41.839 --> 00:07:46.240 or the GCP bill, And that's whenever the finance team comes down and says, 112 00:07:46.279 --> 00:07:50.079 hey, maybe we should take a different approach to this. And so 113 00:07:50.120 --> 00:07:55.360 that's where some you know, that's whenever you've got to break open the hood 114 00:07:55.399 --> 00:08:00.120 on the o RM and really start understanding what queries it's running and is there 115 00:08:00.120 --> 00:08:01.839 are a way to optimize those? That's right, Yeah, And since you 116 00:08:01.879 --> 00:08:05.199 talk about costs, right, I think like these days everybody's like optimizing for 117 00:08:05.240 --> 00:08:07.639 costs, right because like things are expensive, and companies are you know, 118 00:08:07.720 --> 00:08:13.800 laying people off and all the bad stuff. And database so interesting right because 119 00:08:13.800 --> 00:08:16.120 they're quite expensive, but they're also hard to change, right, And so 120 00:08:16.160 --> 00:08:20.000 I think that's that's you know something else I see. Often it's really like 121 00:08:20.040 --> 00:08:22.439 as you mentioned, right, like this like people reach kind of a performance 122 00:08:22.480 --> 00:08:24.680 bottlem like but then they don't know how to solve it, and so they 123 00:08:24.800 --> 00:08:30.000 just upscale database. It's worse is usually in the cloud, your databases go 124 00:08:30.120 --> 00:08:33.919 up and you know slizes of two essentially multiple power of two type things, 125 00:08:33.960 --> 00:08:35.480 right, So like I have sixteen gigabytes to RAM, next you got to 126 00:08:35.480 --> 00:08:39.279 have three two gigabytes TOD then sixty four, right, and so you just 127 00:08:39.399 --> 00:08:43.159 keep essentially like doubling your costs, which is horrible, right. And it's 128 00:08:43.159 --> 00:08:46.799 really hard to not do that because you can't just like have multiple database service 129 00:08:46.840 --> 00:08:50.799 like that requires architecture, like you actually have to think about you know, 130 00:08:50.879 --> 00:08:54.399 can I use read replicas and like if you like split up the read workload 131 00:08:54.960 --> 00:08:56.639 and so stuff like that becomes a challenging problem. Right. So this is 132 00:08:56.639 --> 00:09:01.879 where if you can figure out a very performance issue without scaling up the data 133 00:09:01.879 --> 00:09:05.799 reserve, right, because adding A to the index, for example, then 134 00:09:05.879 --> 00:09:09.039 that you know, connectually safety a lot of money, which is why people 135 00:09:09.039 --> 00:09:13.399 care about it. Oh for sure. Yeah. And I'm not a DBA 136 00:09:13.679 --> 00:09:16.720 by any stretch of the imagination. But the power of indexes, whenever I 137 00:09:16.799 --> 00:09:22.360 discovered that early on in my career, was just mind blowing at at how 138 00:09:22.480 --> 00:09:26.039 much of a difference that would make in the database performance. Yeah for sure. 139 00:09:26.120 --> 00:09:28.600 Yeah, and it's I mean, the good news is, I think 140 00:09:28.919 --> 00:09:33.320 people have gotten better over the years of understanding the basics of indexes. I 141 00:09:33.360 --> 00:09:37.039 think where it's hard, like what's hard to understand if indexes sometimes is that 142 00:09:37.320 --> 00:09:39.679 there's multiple different index types. Right, So Postcress, like the default is 143 00:09:39.679 --> 00:09:43.200 a bea tree, which most people roughly know exceptually what a B tree is. 144 00:09:43.919 --> 00:09:48.000 But Postcress has all these different index types like just gin hash, Britain, 145 00:09:48.600 --> 00:09:52.919 all these like specialized things if you're talking AI and m L, there's 146 00:09:54.000 --> 00:09:58.879 you know kind of future vector has like IBF flat and hsu inex types and 147 00:09:58.960 --> 00:10:03.840 so really the challenge there is understanding when you use these specialized types, right, 148 00:10:03.679 --> 00:10:07.960 But like that's that's essentially what's even verse than the regular indexing problem. 149 00:10:07.960 --> 00:10:09.960 It's just you know, oh, I forgot to add it, and next 150 00:10:09.159 --> 00:10:16.200 which index to that? Great? Yeah, just information overload that. Yeah. 151 00:10:16.519 --> 00:10:26.039 So everyone's talking about AI these days, and I think one of the 152 00:10:26.200 --> 00:10:31.679 one of the stories that we're trying to sell really hard is that AI is 153 00:10:31.759 --> 00:10:35.879 not the tool to replace your job. AI is a tool that helps you 154 00:10:35.960 --> 00:10:41.080 be more proficient at your job because as an engineer today, like you've got 155 00:10:41.080 --> 00:10:46.960 to be versed in so many different things from infrastructure to databases, to the 156 00:10:48.200 --> 00:10:52.759 actual application code that you're writing, to the business knowledge. So what kind 157 00:10:52.840 --> 00:10:56.039 of what kind of assistance can we get from AI and helping understand things like 158 00:10:56.080 --> 00:11:01.919 that like which where we need an index and what type of index? Yeah? 159 00:11:03.120 --> 00:11:05.080 And I think it's it's a complex topic, right, So I think 160 00:11:05.120 --> 00:11:09.759 the answer is I think there are things we should be we should be thinking 161 00:11:09.759 --> 00:11:13.480 about. Is it important that a human is doing activity or can we be 162 00:11:13.639 --> 00:11:16.440 machine assisted at the very least? Right, I don't necessarily know if we 163 00:11:16.480 --> 00:11:18.519 want to be machine driven, right, I don't know if we want to 164 00:11:18.559 --> 00:11:22.200 have the AI kind of take control of our database tuning, for example. 165 00:11:22.480 --> 00:11:24.919 I think you know very much the same way that if you think of the 166 00:11:24.919 --> 00:11:26.159 depth hoops world, right, do we just want to have you know, 167 00:11:26.200 --> 00:11:31.759 AI orchestrate our servers automatically and just provision things? Probably not? Right, 168 00:11:31.840 --> 00:11:33.320 Like things like terror form and stuff are a good thing, Like you want 169 00:11:33.320 --> 00:11:37.639 to have that level control. And so I think with I mean there's a 170 00:11:37.679 --> 00:11:41.360 couple of things going on that field, right, I think at the like 171 00:11:41.480 --> 00:11:45.000 just looking backward the last couple of years, looking outside of what we ourselves 172 00:11:45.000 --> 00:11:46.919 is done, and they we just start with what other people have done. 173 00:11:46.720 --> 00:11:50.679 So just in terms of research, there used to be a project called auto 174 00:11:50.759 --> 00:11:56.399 Tune. There's their company now they essentially do hazing details personally, but they 175 00:11:56.440 --> 00:12:01.960 essentially do like basin statists six based optimization, right, so they do not 176 00:12:03.240 --> 00:12:05.960 use generative AI, right, Like it's not like you're asking Chatchy D how 177 00:12:05.960 --> 00:12:09.000 to optimstic database. What they're essentially doing is saying, for this particular parameter 178 00:12:09.080 --> 00:12:13.159 value, can we run you know, a model that essentially comes up with 179 00:12:13.200 --> 00:12:16.360 the best possible parameter? Right, And it's pretty beff feel like it's it's 180 00:12:16.360 --> 00:12:20.679 a cool idea's a cool system. There's other like there's another startup like that, 181 00:12:20.759 --> 00:12:24.120 Dbtune, which also tries to do with something very similar more recent some 182 00:12:24.200 --> 00:12:28.399 similar idea, right, which is how can we get the best parameter values? 183 00:12:28.480 --> 00:12:31.279 Essentially, so I think that's great. You should take a look at 184 00:12:31.279 --> 00:12:35.480 these if you're interested in tuning parameters. What we have done is pach Analyze 185 00:12:35.519 --> 00:12:41.440 is we've optimized focused on essentially the things that you know, they're a little 186 00:12:41.440 --> 00:12:43.559 bit more fuzzy in terms of who owns them, right, so in you 187 00:12:43.919 --> 00:12:46.679 just want index earlier, and so what we've actually come up with a system 188 00:12:46.720 --> 00:12:52.720 called pach Analys's Index Advisor, which is essentially a recommendation system for which indexes 189 00:12:52.720 --> 00:12:56.480 to create, right, and so different than parameters, right, the parameter 190 00:12:56.519 --> 00:12:58.159 is sometimes a choice, like you kind of want to find tune it, 191 00:12:58.200 --> 00:13:01.240 but you don't necessarily need to do that all the time, or your application 192 00:13:01.279 --> 00:13:05.639 engineers don't need to know how you tune your share buffer parameter in post cress 193 00:13:05.679 --> 00:13:09.919 Like that stuff isn't that important essentially to the application engineer. But indexes are 194 00:13:09.960 --> 00:13:13.519 interesting because they they have like this fuzzy ownership, right, Like is it 195 00:13:13.559 --> 00:13:16.919 the application engineer owning them? Is it the kind of DBA or the platform 196 00:13:16.919 --> 00:13:20.679 engineer owning them? And so what recentially built this system that you know, 197 00:13:20.440 --> 00:13:22.639 imagine it's kind of like your safety harness, right, Like, it doesn't 198 00:13:22.639 --> 00:13:26.840 necessarily say you you've got to drive your decisions, but if you forget to 199 00:13:26.840 --> 00:13:28.840 add an index, it will tell you. And so it's not you know 200 00:13:28.919 --> 00:13:31.200 what I call it AI. I don't know, right, AI is a 201 00:13:31.200 --> 00:13:33.960 complex term. It's not chene AI, right, Like, it's not chanitif 202 00:13:35.000 --> 00:13:37.679 I the same way as auto tune or DBTN or not chanitif I. But 203 00:13:37.759 --> 00:13:41.360 it is a way to essentially have a recommendation, uh, kind of of 204 00:13:41.519 --> 00:13:46.279 which things to create based on your career, work club, right, and 205 00:13:46.320 --> 00:13:48.919 so similar spirit, what we've also done is what we call vacuum Advisor. 206 00:13:50.159 --> 00:13:52.600 And so vacuum and postcress is very particular concept. You may not be familiar 207 00:13:52.639 --> 00:13:58.240 with it, but essentially it's it's essentially that the dead row cleanup and postcress 208 00:13:58.279 --> 00:14:01.600 rights like when you have like you've been update or delete postgress you know, 209 00:14:01.639 --> 00:14:07.080 will create essentially a record that kind of just marks the deleted data essentially, 210 00:14:07.559 --> 00:14:09.399 and then vacuum comes and cleans that up. And so sometimes you need to 211 00:14:09.399 --> 00:14:13.120 find tune the schedule of that, right, you need to understand how often 212 00:14:13.159 --> 00:14:15.519 is it running? Is running too often or not often enough? Is it? 213 00:14:15.559 --> 00:14:18.679 You know, kind of like running it wrong time a day, right, 214 00:14:18.720 --> 00:14:20.679 like I have my business hours and suddenly the database is busy a vacuum. 215 00:14:20.960 --> 00:14:24.639 And so we've essentially done something where we looked at all the time serious 216 00:14:24.720 --> 00:14:28.000 data that we have in our system and we said, you know, can 217 00:14:28.039 --> 00:14:31.399 we make your recommendations for which confex stennings to change. This kind of goes 218 00:14:31.440 --> 00:14:33.799 a little bit into that parameter tuning area. What we then do is we 219 00:14:33.840 --> 00:14:37.440 do is on a per table basis, and so this is then again where 220 00:14:37.759 --> 00:14:41.039 if you as a human did that, it just becomes very complicated, right 221 00:14:41.039 --> 00:14:43.919 because you've got to think of like imagine our own database. For example, 222 00:14:43.919 --> 00:14:46.759 we have a thousand tables. If you have a thousand tables, looking at 223 00:14:46.799 --> 00:14:48.960 each and every one of them and then looking at you know, a graph 224 00:14:50.039 --> 00:14:52.679 over time that describes to you how you know the auto vacuum works. It's 225 00:14:52.720 --> 00:14:56.879 just very tedious. And so being able to have that automatically kind of looked 226 00:14:56.879 --> 00:15:01.159 at an analyzed is really what I've found quite useful over the years. And 227 00:15:01.480 --> 00:15:03.919 what we done, oh for sure, that's to me, that's like pure 228 00:15:05.000 --> 00:15:09.759 gold right there, because you know, like I know that you have to 229 00:15:09.159 --> 00:15:13.120 vacuum postpress databases, and when I first encountered that, I was like, 230 00:15:15.399 --> 00:15:18.919 what the hell I have to vacuum this thing? Like can I hire a 231 00:15:20.000 --> 00:15:22.679 housekeeper? Or how does this work? And then you want to do it? 232 00:15:22.919 --> 00:15:26.759 Yeah? Yeah, and then so then yeah, that was just led 233 00:15:26.799 --> 00:15:28.320 to more questions for me, like, well, should I trust this built 234 00:15:28.320 --> 00:15:31.360 in housekeeper? When's it going to do it? How do I know if 235 00:15:31.360 --> 00:15:35.320 it's doing it at the right time? And so to have a tool that 236 00:15:35.519 --> 00:15:39.559 looks at what's actually going on in my data database and then makes recommendations based 237 00:15:39.600 --> 00:15:46.159 on that activity, I think it is just like an amazing resource to have 238 00:15:46.440 --> 00:15:50.960 because it answers so many questions for me that that I didn't even know we're 239 00:15:52.000 --> 00:15:56.879 supposed to be questions, right exactly, Yeah, And I think especially if 240 00:15:56.919 --> 00:15:58.840 you, if you like are not a pubicles expert, right, like, 241 00:15:58.840 --> 00:16:03.559 this is what I've seen order hears is like people migrate from Oracle to postcress 242 00:16:03.600 --> 00:16:06.679 or from civile server to postcress, and these databases they do this differently, 243 00:16:06.759 --> 00:16:08.639 right, so they don't have vacuum as a concept, And so people when 244 00:16:08.639 --> 00:16:11.519 they first go to postcress and then they have this bike production system. Suddenly 245 00:16:11.559 --> 00:16:15.200 these vacuum problems start happening, and they're like, what's going on? Like 246 00:16:15.480 --> 00:16:17.720 what should I do? Right, Like I don't have anybody in house who 247 00:16:17.720 --> 00:16:22.679 knows about this. Yeah, yeah, and you can always post on stack 248 00:16:22.720 --> 00:16:26.440 overflow and hope for the best. There there are some good people on stack 249 00:16:26.480 --> 00:16:30.039 overflow. Let me talk like, it's really you know, I've I've learned 250 00:16:30.039 --> 00:16:34.360 this thing or two or ten from a stack overflow posts for sure. Yeah, 251 00:16:34.480 --> 00:16:41.799 it's it's funny because like there's the learning curve of stack overflow, like 252 00:16:41.840 --> 00:16:47.519 it's it's this tremendous resource, but you have to learn how to interact with 253 00:16:47.639 --> 00:16:51.720 you know, how to here's the minimum criteria I have to have to open 254 00:16:52.000 --> 00:16:55.480 the question, you know, and here's what I've got to include if I'm 255 00:16:55.480 --> 00:17:00.000 going to get a legitimate value response, right, And I think what's interesting 256 00:17:00.440 --> 00:17:03.960 on the topic of psago flow that that actually makes me think in terms of 257 00:17:04.039 --> 00:17:07.920 AI, that makes me think of gen AI, right, Like the whole 258 00:17:07.599 --> 00:17:11.000 you know, kind of give me a response that resempless stechgorical answer is I 259 00:17:11.000 --> 00:17:15.240 think what generator A I and LMS are good at and so somebody in the 260 00:17:15.240 --> 00:17:21.480 postgars community and Nicolai from postgrass Ai. He's a recent project where he's essentially 261 00:17:21.480 --> 00:17:26.480 connected to cheat GPT with kind of a knowledge base of different postgress articles and 262 00:17:26.519 --> 00:17:29.359 it's actually a really interesting experiment. But he's essentially saying, what if we 263 00:17:29.400 --> 00:17:32.160 had a chatbot, you know, that was power by chat, ChiPT or 264 00:17:32.279 --> 00:17:36.200 GPT for I think, and then you would essentially ask a question just like, 265 00:17:36.599 --> 00:17:38.200 you know, how do I set this parameter in postcars and then will 266 00:17:38.240 --> 00:17:41.559 just spit out something that essentially looks like a Stachofal answer, which I think 267 00:17:42.039 --> 00:17:45.160 like that has has this place as well, right because people, I think 268 00:17:45.200 --> 00:17:49.240 what people do alternatively to asking a chat about that, they'll go on Google 269 00:17:49.240 --> 00:17:52.720 and they'll search how to tune this parameter. And then, unfortunately, with 270 00:17:52.839 --> 00:17:56.039 you know, the advance of AI, what has happened is a lot of 271 00:17:56.079 --> 00:18:00.799 more articles are just not that useful because it's beau, I'm pretty cheap to 272 00:18:00.839 --> 00:18:03.960 generate, you know, kind of that constant sense. And so what he's 273 00:18:03.960 --> 00:18:04.920 done is really, you know, kind of I think, built a better 274 00:18:04.920 --> 00:18:08.200 solution to you know, how do I get good postters knowledge? Is by 275 00:18:08.279 --> 00:18:12.480 essentially building off with you before and having kind of this this more trusted I 276 00:18:12.480 --> 00:18:18.240 think data like database of good articles, which I found interesting. Yeah. 277 00:18:18.279 --> 00:18:23.440 I don't think it's going to be truly successful though until chat GPT actually sends 278 00:18:23.440 --> 00:18:29.200 out insulting answers at random just to insult your intelligence, until you to come 279 00:18:29.200 --> 00:18:33.680 back when you actually know how to ask an intelligent question. Yeah. Yeah, 280 00:18:33.680 --> 00:18:34.960 And it has some weird issues like earlier this week, I just I'm 281 00:18:34.960 --> 00:18:37.880 not an active chutch up to user personally, but you know that there was 282 00:18:37.920 --> 00:18:42.640 like this issue where it just like started screwing RD and garbage. It's certainly 283 00:18:42.920 --> 00:18:45.880 you know sometimes I mean it's it's interesting in a sense, right, Like 284 00:18:45.920 --> 00:18:48.720 it feels like I'm reading a science fiction novel and I not to get sure 285 00:18:48.720 --> 00:19:02.519 where it's going. Right. Cool, So let's go back to to someone 286 00:19:02.599 --> 00:19:08.599 who's who's working with postgress, you know, has multiple other roles, and 287 00:19:08.640 --> 00:19:12.680 we talked about, you know, the need for indexes and query optimization. 288 00:19:14.400 --> 00:19:21.480 But that's like pretty pretty specific, like you're you're narrowing in on the actual 289 00:19:21.559 --> 00:19:26.759 problem there. What are the indicators before that that tell them that this is 290 00:19:26.759 --> 00:19:29.880 the area what you want to focus on, Like you're running postgress. What 291 00:19:29.960 --> 00:19:33.279 kind of things do you see that tell you, hey, this is a 292 00:19:34.319 --> 00:19:37.960 something that postgress might help with, versus this is something that looks like it's 293 00:19:38.000 --> 00:19:44.559 application code or infrastructure related. Yeah. No, it's a good question. 294 00:19:44.680 --> 00:19:45.799 I think it's it's actually not an easy problem to solve, right, because 295 00:19:45.839 --> 00:19:49.759 you you're kind of looking at two different worlds. Right. So I think 296 00:19:49.799 --> 00:19:53.559 that what people most commonly would have is they would have like an APM tool 297 00:19:53.559 --> 00:20:00.599 of sorts or tracing toolrights that might be using you relic data dog like long 298 00:20:00.680 --> 00:20:04.039 list of apmtals, right, Yeah. And so what you were seeing these 299 00:20:04.079 --> 00:20:07.599 tools is you would see a trace for example, right, these as you 300 00:20:07.599 --> 00:20:11.200 would call a trace, and you would say, here's a slow request, 301 00:20:11.200 --> 00:20:14.759 and you would see different spans essentially in the trace that would say you know 302 00:20:14.759 --> 00:20:18.400 which part of request is slow? And so usually with most of these instrumentations, 303 00:20:18.480 --> 00:20:22.920 you from the application side, you will know that the query is the 304 00:20:22.960 --> 00:20:25.079 slow part. Right, So you would I would expect, let's say, 305 00:20:25.279 --> 00:20:27.240 with a request that takes ten seconds, we would see that you know, 306 00:20:27.279 --> 00:20:30.000 out of these ten seconds, nine seconds are spent in the database. Great, 307 00:20:30.039 --> 00:20:33.440 right, So this is this is actually just something that you will get 308 00:20:33.480 --> 00:20:37.759 most of the time. Not a hard part is understanding is this something I 309 00:20:37.759 --> 00:20:40.720 could do something about, right, because it's essentially will say, here's a 310 00:20:40.720 --> 00:20:42.519 sequel query and here is you know, this nine seconds span, but it 311 00:20:42.519 --> 00:20:48.319 doesn't tell you anything more about it. And so what I've found quite interesting 312 00:20:48.759 --> 00:20:52.799 we've uh, we've kind of launched this feature also last year, is we 313 00:20:52.160 --> 00:20:59.400 essentially use the fact that open telemetry allows you to connect different essentially different services. 314 00:20:59.440 --> 00:21:02.680 Right. So the idea in a microservice architecture is you can have different 315 00:21:02.960 --> 00:21:07.799 systems sent into the same trace essentially. And so imagine that if your database 316 00:21:07.839 --> 00:21:11.119 could tell you, hey, you know these nine seconds of time, Actually 317 00:21:11.160 --> 00:21:15.119 I spent five seconds scanning this index, four seconds joining this data, right, 318 00:21:15.319 --> 00:21:18.480 Suddenly your trace becomes much more usable, right because you're not looking at 319 00:21:18.519 --> 00:21:22.079 this you know, nine second time span. You're actually looking at individual operations 320 00:21:22.079 --> 00:21:25.480 that you maybe understand better, right because you're doing a big quer on this 321 00:21:25.519 --> 00:21:30.240 table. And so what we've actually done essentially is piggyback on this idea of 322 00:21:30.279 --> 00:21:33.440 different services sending into the you know, same system, the same observability system. 323 00:21:33.759 --> 00:21:38.000 And so we've built an integration where we pull the kind of a slow 324 00:21:38.079 --> 00:21:42.519 query log or auto explained log in postgrass, which essentially says, here is 325 00:21:42.559 --> 00:21:45.319 you know a slow queer execution, and here's the plan for that execution, 326 00:21:45.640 --> 00:21:48.680 and so we pulled that as part of our kind of agent, and then 327 00:21:48.720 --> 00:21:53.839 we send the essentially a reference of that information into the tracing system. Right. 328 00:21:55.319 --> 00:21:56.920 And so what the solves is what you would do otherwise. Right. 329 00:21:56.960 --> 00:22:00.279 So let's imagine if you don't have this type of solution, is you look 330 00:22:00.279 --> 00:22:03.200 at your trace and you have that nine second span, and then you have 331 00:22:03.279 --> 00:22:07.359 to correlate that with the database activity. Right, So you would essentially either 332 00:22:07.359 --> 00:22:11.359 look at your database logs or like in postcristers, tools like ggstat statements which 333 00:22:11.400 --> 00:22:14.519 tracks the query performance over time. And so what you would do is you 334 00:22:14.640 --> 00:22:17.400 essentially say, well, I know roughly the query shape, right, formatting 335 00:22:17.480 --> 00:22:19.359 sometimes differs slightly, but maybe you know, I'll like copy and paste a 336 00:22:19.359 --> 00:22:22.000 part of the query. I'll go over to the database and I'll kind of 337 00:22:22.240 --> 00:22:26.039 put it in and I'll try to find the thing that's matching that looks like 338 00:22:26.079 --> 00:22:29.599 the right query. But it's really hard to do that precisely. And so 339 00:22:29.680 --> 00:22:33.720 this is I think where open telemetry really has an interesting way of solving this, 340 00:22:33.880 --> 00:22:37.599 right, because just expand that briefly, what essentially it does is in 341 00:22:37.680 --> 00:22:41.200 tracing, you have these IDs right as you're trying to propagate across systems. 342 00:22:41.759 --> 00:22:45.599 And so the idea is when you run a CQL career, you add a 343 00:22:45.640 --> 00:22:48.799 comment and in a comment that says what's the trace ID and the parent span 344 00:22:48.839 --> 00:22:52.240 ide of that query is. And so when the query arrives on the database 345 00:22:52.279 --> 00:22:56.359 side, the database can output a log for example, that says, hey, 346 00:22:56.400 --> 00:22:57.759 you know, this career was slow. Here's the career plant. And 347 00:22:57.799 --> 00:23:02.200 also, by the way, here's the little comment at the start that tells 348 00:23:02.240 --> 00:23:04.960 you that tells the tracing system essentially how to kind of stitch that back together 349 00:23:06.039 --> 00:23:11.319 into one unified view of the world, right, Yeah, And that's the 350 00:23:11.480 --> 00:23:15.880 Open Telemetry has just made some huge strides in tying all of that together. 351 00:23:17.000 --> 00:23:22.640 We had Andy Grabner from Dinah Trace on the show yesterday and we ended up 352 00:23:22.680 --> 00:23:30.359 talking about open telemetry there as well, and just the like the whole, 353 00:23:33.359 --> 00:23:37.920 you know, the whole community effort from all of these different players to agree 354 00:23:37.079 --> 00:23:41.880 like, hey, we can all use this standard and create this system that 355 00:23:41.960 --> 00:23:45.440 allows you to tie those kinds of things together. It's pretty cool and something 356 00:23:45.440 --> 00:23:49.160 that I don't think we we could have seen in our industry up until the 357 00:23:49.240 --> 00:23:53.359 last few years. Yeah, for sure. And I think open Elementary is 358 00:23:53.400 --> 00:23:57.559 interesting because it has that like cross company collaboration. Right, So like Dina 359 00:23:57.599 --> 00:24:02.880 Trace is involved in a standard, it's Microsoft that are like big players involved. 360 00:24:02.920 --> 00:24:06.920 Like it just seems like I'm like, I'm positively surprised essentially that they 361 00:24:06.960 --> 00:24:08.000 were all able to come to the table, and like some of them are 362 00:24:08.039 --> 00:24:11.960 vendors, some of them are you know, big customers of observability data, 363 00:24:11.200 --> 00:24:14.519 and even if some of them are selling their own solutions, right, they 364 00:24:14.519 --> 00:24:17.359 are essentially still at the table discussing, hey, how can make the standard 365 00:24:17.359 --> 00:24:18.960 work? Yeah, which is an end user is actually great, right because 366 00:24:19.000 --> 00:24:23.000 you kind of go out of this vendor specific instrumentation in your code and you're 367 00:24:23.039 --> 00:24:27.000 moving more towards the standardized instrumentation and you can choose different vendors. So I 368 00:24:27.039 --> 00:24:30.359 think that's that's how things should be. Yeah. Yeah, And then the 369 00:24:32.559 --> 00:24:36.279 skeptical side of me sees that and it's like, hmm, okay, what's 370 00:24:36.319 --> 00:24:41.319 the catch. I mean, I think the catches it's it's sometimes sometimes the 371 00:24:41.319 --> 00:24:44.240 story is a little bit oversold, right, So I've spent a lot of 372 00:24:44.319 --> 00:24:47.359 time and some of you know, some of the maybe more niche use cases, 373 00:24:47.440 --> 00:24:49.240 right, and the whole thing we just like I've just talked about in 374 00:24:49.359 --> 00:24:52.720 terms of commenting and such like. For example, there's a project called SQL 375 00:24:52.720 --> 00:24:56.440 Commentary which is supposed to add these query tags. In the beginning, that's 376 00:24:56.440 --> 00:25:02.200 the project at Google actually donated to the Open Climate project. And it's great 377 00:25:02.240 --> 00:25:04.119 they've donated it, but also it's kind of stall since then, so it's 378 00:25:04.119 --> 00:25:07.519 not like they've actually pushed forward and really said, hey, you know, 379 00:25:07.559 --> 00:25:08.640 how do we make this, you know, a proper standard, how do 380 00:25:08.640 --> 00:25:11.960 we document this as part of the official project? And so sometimes I think 381 00:25:12.440 --> 00:25:18.359 the risk essentially of these stanardization projects is that sometimes you know, there is 382 00:25:18.400 --> 00:25:19.960 like this you know, Alpha spec to do something, or like this thing 383 00:25:21.000 --> 00:25:23.359 that was contributed by one of the players, but there's not enough momentum around 384 00:25:23.599 --> 00:25:27.119 actually developing the standard further. And so I think, for example, if 385 00:25:27.119 --> 00:25:30.200 I was doing tracing right, definitely do the open plamage tracing stuff. But 386 00:25:30.240 --> 00:25:33.880 if you're doing logs even right, like logs are like they're pretty stable in 387 00:25:33.920 --> 00:25:37.839 open plemagry understanding but they're still less, you know, kind of commonly, 388 00:25:37.960 --> 00:25:42.759 kind of fully supported across all different languages and whatnot. Right, Yeah, 389 00:25:44.000 --> 00:25:52.720 so you've got a ton of experience with Postgress. There are there's quite a 390 00:25:52.759 --> 00:25:56.480 few database choices available. I mean really in my mind, there's like there's 391 00:25:56.720 --> 00:26:04.000 Postgrass, my sequel, and Mango. I consider those to be like the 392 00:26:04.000 --> 00:26:08.200 big players. And there's different variants of that, you know, and you 393 00:26:08.240 --> 00:26:11.599 know when you get off into the no SQL stuff, you know, there's 394 00:26:11.599 --> 00:26:15.079 different use cases there. But I really see it as being like those three 395 00:26:15.400 --> 00:26:21.440 as being the most prevalent. What are the things? And I've used Postgress 396 00:26:21.480 --> 00:26:25.400 a ton because it just seems to fit any use case you throw at it. 397 00:26:25.440 --> 00:26:30.599 But what are you what's your your take on why Postgress versus some of 398 00:26:30.640 --> 00:26:34.839 the other database offerings. Yeah, and I would add, like, just 399 00:26:34.839 --> 00:26:37.160 just to add the fourth to the list, I would say these days out 400 00:26:37.200 --> 00:26:41.039 of a ClickHouse to the list as well. In terms of source databases, 401 00:26:41.039 --> 00:26:45.640 it's not relational like like or it's a column store essentially. But I've definitely 402 00:26:45.640 --> 00:26:48.960 seen a lot of companies use posts and ClickHouse for different workload, different parts 403 00:26:48.960 --> 00:26:56.079 of workloads. But yeah, I would say you know the it's so so 404 00:26:56.119 --> 00:27:00.000 I think that like there's there's different reasons why you use postosts, why use 405 00:27:00.039 --> 00:27:03.440 from ones. One of the things that I usually talk about open clemmmetry and 406 00:27:03.440 --> 00:27:06.400 different companies coming together, right, and it's from a community perspective. The 407 00:27:06.480 --> 00:27:08.400 one thing like what keeps me the postcrist community, right, which is not 408 00:27:08.519 --> 00:27:11.359 exactly answering your question, but I think it is an interesting aspect of this 409 00:27:11.720 --> 00:27:15.400 is postcurs is not a project by Bond company, right. Post Chris is 410 00:27:15.400 --> 00:27:18.279 a community project. Like it has you know, people from ab guests working 411 00:27:18.319 --> 00:27:22.160 in it, people from Microsoft working from ed B working it, from Google 412 00:27:22.200 --> 00:27:25.519 working in it, people from small companies plant working it. And it is 413 00:27:25.559 --> 00:27:27.720 a true community project, kind of like Linux currently is. And I think 414 00:27:27.759 --> 00:27:30.960 this this is what fascinates me about it and what makes me, you know, 415 00:27:32.079 --> 00:27:36.200 just the longevity of it is like so much. Essentially I trust it 416 00:27:36.240 --> 00:27:37.920 to be to have that longevity even in you know, ten years, twenty 417 00:27:38.039 --> 00:27:42.400 fifty years from now, just because it's it's it's been able to kind of 418 00:27:42.480 --> 00:27:45.000 advance over the years, but it's also been able to do that as a 419 00:27:45.000 --> 00:27:48.519 community project, not as a commercial player trying to you know, kind of 420 00:27:49.359 --> 00:27:52.720 get both benefits essentially, right, because if you look at mangoay to be, 421 00:27:52.839 --> 00:27:55.880 like mamay B has you know, their ATHLETs service, And I don't 422 00:27:55.920 --> 00:27:57.920 know how it differs between you know what mama to be open source gets you 423 00:27:59.039 --> 00:28:00.839 versus you know, the Atlas base Mango to be. But certainly, you 424 00:28:00.839 --> 00:28:03.440 know, I would imagine they have that conflict, right They're constantly thinking what 425 00:28:03.480 --> 00:28:07.000 should I put there? What should it? But there are people just going 426 00:28:07.039 --> 00:28:10.160 to deploy their own, right, and so just that that is really I 427 00:28:10.160 --> 00:28:11.440 think you know why postcrists is a great building block, right, because it 428 00:28:11.440 --> 00:28:17.519 doesn't have that that fundamental conflict that these companies usually have. I think when 429 00:28:17.519 --> 00:28:21.400 you're trying to make a decision which one to use, I think if you're 430 00:28:21.480 --> 00:28:23.559 using my sequel, there's you know, there's some reasons to migrate to postgress, 431 00:28:23.559 --> 00:28:26.000 but they're they're usually not that strong, right, So I think when 432 00:28:26.039 --> 00:28:30.079 I see people migrating between the databases, it's really more to old school like 433 00:28:30.119 --> 00:28:33.920 Oracle or SQL server to post press, right, And for example there postcrists 434 00:28:33.960 --> 00:28:37.039 is a very good target for these migrations because it has like a lot of 435 00:28:37.039 --> 00:28:41.400 similarities in some sense and career language and such before Orecle for example, and 436 00:28:41.400 --> 00:28:45.119 stuff like that. There's easy it's easier to migrate essentially to post Christ into 437 00:28:45.119 --> 00:28:48.240 my sequel. Also, if you're using Oracle, why would you go to 438 00:28:48.240 --> 00:28:52.559 my sqel because that's owned by Oracle. Again, kind of doesn't really make 439 00:28:52.599 --> 00:29:00.079 sense. And I think Mango to be I don't, you know, I 440 00:29:00.079 --> 00:29:03.759 don't have much experience personally, but I think it's like really it's it's it's 441 00:29:03.799 --> 00:29:07.160 the kind of thing where you make a choice. Sometimes companies, you know, 442 00:29:07.240 --> 00:29:11.440 run multiples of those, like oftentimes I see companies just as in Postcriss, 443 00:29:11.720 --> 00:29:14.319 I think you can scale out all of these right like Postcress as Citas. 444 00:29:14.559 --> 00:29:17.720 My sequel has the tests and planet scale. I'm I'm going to be 445 00:29:17.799 --> 00:29:19.559 kind of as it's built in way of scaling out. So it's it's you 446 00:29:19.599 --> 00:29:22.400 don't you don't really run into a bottom like these days anymore with not being 447 00:29:22.400 --> 00:29:27.000 able to scale beyond a certain data poet. Yeah, for sure. Yeah. 448 00:29:27.039 --> 00:29:33.880 My introduction to Mango deb was gosh, it's been I think it's been 449 00:29:33.920 --> 00:29:41.279 over ten years ago now, but where we used it was with mobile applications, 450 00:29:41.920 --> 00:29:48.279 uh, and user attribution because you have this application that ties into all 451 00:29:48.359 --> 00:29:52.279 these different services, you know, like ties into Facebook and ties into Amazon 452 00:29:52.400 --> 00:29:56.519 and different things like that, and you're trying to attribute your marketing campaigns to 453 00:29:56.640 --> 00:30:03.200 those platforms, but with each one and you get different data. And so 454 00:30:03.359 --> 00:30:07.799 Mango for us turned out to be a really good way to just say, 455 00:30:07.799 --> 00:30:11.759 Okay, here's the attribution data we got for this user, and we're just 456 00:30:11.799 --> 00:30:15.880 gonna put it in this Mango field. And then in some cases we know 457 00:30:15.039 --> 00:30:22.440 that there's one key value pair that's consistent across all of those platforms, and 458 00:30:22.480 --> 00:30:25.559 then we're gonna keep the rest of the stuff around because we might end up 459 00:30:25.640 --> 00:30:29.079 needing it later too, And so that was a really strong use case for 460 00:30:29.200 --> 00:30:36.079 Mango. Now Postgress also though, supports Jason data types, so you could 461 00:30:36.160 --> 00:30:38.960 just as easily have done it with Postgress. I don't know if Postgress actually 462 00:30:40.000 --> 00:30:41.480 had it back when we did this, but I know what that it is 463 00:30:41.519 --> 00:30:45.759 there now, yeah, and what it probably had. So there's you know, 464 00:30:45.799 --> 00:30:48.039 I would say, there's three things worth thinking about and knowing about it, 465 00:30:48.079 --> 00:30:49.880 right, So, Like the simplest thing is you could always just store 466 00:30:49.960 --> 00:30:53.240 texts like Jason has texting your database, right, right, But what you're 467 00:30:53.279 --> 00:30:56.599 kind of losing there is like any sense of validation, right, Like if 468 00:30:56.599 --> 00:30:59.839 you're missing a parenthesies, you're not going to database if going to tell you, 469 00:30:59.920 --> 00:31:03.920 right, And so the most simplest form, postcress has adjacent data type 470 00:31:03.200 --> 00:31:07.480 and Jason in postcus is really just a validation step right where it says, 471 00:31:07.480 --> 00:31:11.160 okay, well let me conform to this actual correct Jason, and then you 472 00:31:11.200 --> 00:31:14.000 know it can do some operations on top of it. But really, where 473 00:31:14.160 --> 00:31:18.440 I think postcress has become more of a competitive Mango to B is the Jason 474 00:31:18.519 --> 00:31:22.119 B data type. B stands for binary, and the idea behind data is 475 00:31:22.200 --> 00:31:26.279 that it lets you, amongst other things, index a Jason B kind of 476 00:31:26.319 --> 00:31:29.640 field, similar to how you could indexes with Mongo. Right. So, 477 00:31:29.720 --> 00:31:33.599 like the idea is that if you know, I have this like schema less 478 00:31:33.640 --> 00:31:34.799 data of sorts, like I don't know exactly the shape of it or what 479 00:31:34.880 --> 00:31:37.559 comes what's gets thrown into it, but I usually want to query for some 480 00:31:37.680 --> 00:31:40.519 of the keys, right, and I want to search for things and that 481 00:31:40.680 --> 00:31:45.079 taste that essentially, then the way that you can do this nowadays with post 482 00:31:45.119 --> 00:31:47.839 presses, you have a Jason B, you have a gin index or in 483 00:31:47.920 --> 00:31:52.480 some cases just in necess' on the on Jason B column and you could just 484 00:31:52.559 --> 00:31:55.440 do queries on it. But you don't have to declare upfront what you can 485 00:31:55.480 --> 00:31:56.960 to query, right, You don't have to say, I'm always going to 486 00:31:57.079 --> 00:32:00.839 query for you know, this campaign, idea field or just you know, 487 00:32:00.960 --> 00:32:04.920 other kind of whatever the fields are. But you could actually have a kind 488 00:32:04.920 --> 00:32:08.079 of more generic index. And so that's really I think what you know these 489 00:32:08.160 --> 00:32:12.359 days if you're storing Jason and the postcars definitely used Jason because there's no reason 490 00:32:12.440 --> 00:32:15.440 not to, or almost no reason not to. And so that I think, 491 00:32:15.480 --> 00:32:19.119 you know, gives you gets you ninety five percent of the use cases 492 00:32:19.160 --> 00:32:22.000 that I'm going to be usually would have. Yeah, and you're still in 493 00:32:23.160 --> 00:32:30.319 a database platform that supports relational data as well, and that's I think to 494 00:32:30.400 --> 00:32:35.720 me, that's huge because every application, every business does have relational data, 495 00:32:36.079 --> 00:32:40.160 and so now you're able to accomplish that in a single database platform versus juggling 496 00:32:40.319 --> 00:32:45.079 multiple database connections and trying to remember which one has which data that's right. 497 00:32:45.160 --> 00:32:49.559 Yeah, And on that note, more recently, also so talking about AI, 498 00:32:50.799 --> 00:32:54.839 we like in the postal community, somebody called Andrew Caine, I create 499 00:32:54.880 --> 00:33:00.839 a product called pg vector. Excuse me pg vector and pegbackctor essentially does is 500 00:33:00.880 --> 00:33:04.480 it stores vector embeddings inside Postgress so that you don't have to use a dedicated 501 00:33:04.559 --> 00:33:07.680 vector database instead. It's essentially the same idea, right, Like you have 502 00:33:07.119 --> 00:33:13.559 essentially a special like column like data type that has special indexes, and then 503 00:33:13.640 --> 00:33:15.920 you can store you know, like if you're trying to you know, build 504 00:33:15.920 --> 00:33:20.119 all these AI applications, instead of now using specialized dabases, you can just 505 00:33:20.240 --> 00:33:22.319 use your Postgress And really the big benefit that people are seeing these days, 506 00:33:22.359 --> 00:33:25.079 right is that they can then also keep the rest of the data in Postgress. 507 00:33:25.119 --> 00:33:28.960 Right, So you're building your cool, fancy AI startup, you can 508 00:33:29.039 --> 00:33:31.799 now you know, use Postgress for everything up to a certain limit. Right. 509 00:33:31.839 --> 00:33:35.640 So there are still benefits to using a specialized database, but especially when 510 00:33:35.640 --> 00:33:38.440 you're starting out, it's just so much simpler to stay within one system and 511 00:33:38.519 --> 00:33:43.279 then later on, you know, you kind of scale down. And I 512 00:33:43.319 --> 00:33:45.000 do want to mention at that point, right. Part the reason we talk 513 00:33:45.039 --> 00:33:50.079 different database technologies. One of the reasons why Postgress is very good at, 514 00:33:50.160 --> 00:33:53.920 you know, kind of supporting these newer things like the embeddings is because it 515 00:33:53.960 --> 00:33:58.279 has a very good extension system. So compared to for example, my SQL, 516 00:33:58.519 --> 00:34:00.720 it's much easier in postgress to create an extension that changes some of the 517 00:34:00.799 --> 00:34:06.240 core functionality and postcress that hooks into different parts. There's more of a community 518 00:34:06.279 --> 00:34:09.440 around that also that kind of releases these extensions. And so the fact that 519 00:34:09.480 --> 00:34:12.960 you know, somebody like three years ago Andrew Kaine was like, yes, 520 00:34:13.039 --> 00:34:15.039 I gotta you know, built this library called pg vector and I'll just publish 521 00:34:15.079 --> 00:34:17.719 this. You know, it's an extension of postgress. And then you know, 522 00:34:17.840 --> 00:34:22.519 all the big ciut companies like a ws GCP Azure, they're all like, 523 00:34:22.800 --> 00:34:24.039 yes, AI, you know, it's the best thing, and by 524 00:34:24.079 --> 00:34:27.360 the way, we support AI. And then you look at it and it's 525 00:34:27.400 --> 00:34:30.639 just pgo vector kind of you know, sitting under in the database actually, 526 00:34:30.159 --> 00:34:32.159 like they just went and used the extension. I mean, it's cool, 527 00:34:32.159 --> 00:34:36.760 they did it right, like they they made it accessible and usable. But 528 00:34:37.000 --> 00:34:43.280 it's it's fascinating how you know that extension system allows this adaptability of postprice essentially, 529 00:34:43.840 --> 00:34:49.000 yeah, for sure. And I think that you know, that sets 530 00:34:49.079 --> 00:34:53.119 up the stage so that you can empower your engineers so that they can focus 531 00:34:53.360 --> 00:34:59.679 on application performance, right, Yeah, that's right. And I think also 532 00:35:00.039 --> 00:35:02.880 not learning about the completely new system, right because they will have to be 533 00:35:04.719 --> 00:35:07.519 installing the driver probably like on the application site, or I probably wouldn't support 534 00:35:07.559 --> 00:35:10.480 it, right, Like there's all this extra steps that they would have to 535 00:35:10.519 --> 00:35:16.679 take if to use them completely different. So yeah, and you know, 536 00:35:16.800 --> 00:35:22.000 going back again to talking about the number of technologies and fields we have to 537 00:35:22.079 --> 00:35:29.719 have expertise in. Really that's like the overall objective for all of those is 538 00:35:29.800 --> 00:35:35.440 to create a performance app that moves our business forward. Because most of us 539 00:35:35.599 --> 00:35:43.079 are not in the business of running postcress databases or building AWS infrastructure. That's 540 00:35:43.199 --> 00:35:46.239 just the means to an end for whatever our company is actually trying to do. 541 00:35:47.199 --> 00:35:53.400 Agree, where do you see? Where do you see postgress and pg 542 00:35:53.559 --> 00:35:58.079 analyze going from here? Because we're still in the early stages of AI, 543 00:35:58.159 --> 00:36:00.840 still trying to figure out what it means. And I think you might agree 544 00:36:00.880 --> 00:36:07.039 with me that AI is not a job killer but a job enabler. I 545 00:36:07.079 --> 00:36:08.519 always say it's complicated, right, I think for some people it's definitely job 546 00:36:08.599 --> 00:36:12.559 killer. Right. So if you are in the creative industries, and let's 547 00:36:12.559 --> 00:36:15.079 say you used to like, let's see you're an artist, but you used 548 00:36:15.079 --> 00:36:19.000 to get money from you know, working advertising campaigns. All turns outs, 549 00:36:19.039 --> 00:36:21.440 you know, Open the Eye just released Sora, which you know makes your 550 00:36:21.440 --> 00:36:24.519 whole video production pipeline much easier to you know, just automate with AI. 551 00:36:24.920 --> 00:36:28.679 And so maybe you're out of a job, right because like suddenly your creative 552 00:36:28.679 --> 00:36:31.960 industry's job is just no longer paid, like you can still keeping an artist, 553 00:36:32.079 --> 00:36:36.559 right, there's just no money to be made. So I would disagree 554 00:36:36.639 --> 00:36:38.079 saying, you know, it's uh, it's definitely taking jobs, right, 555 00:36:38.119 --> 00:36:45.000 Like that is very clear. I think it's that's in a sense how when 556 00:36:45.079 --> 00:36:46.159 change is happening, that happens, but it's also shitty, right, like 557 00:36:46.239 --> 00:36:50.199 it causes all kinds of problems. So yeah, I think you have to 558 00:36:50.239 --> 00:36:53.199 accept that too. But I think when I think about, you know, 559 00:36:53.280 --> 00:36:58.079 more personally, in terms of what I see right like happening in my like 560 00:36:58.719 --> 00:37:00.760 niches of the world, right, which is like engineering and data is optimization. 561 00:37:01.119 --> 00:37:04.639 I think as mentioned data is optimization. I'm not sure how much this 562 00:37:04.760 --> 00:37:07.320 is a generative problem, right, So there to me, the natural language 563 00:37:07.360 --> 00:37:13.440 aspect of it is more a maybe I you know, there's there's a semi 564 00:37:13.480 --> 00:37:16.000 automated system that can solve some of these problems for me. But instead of 565 00:37:16.119 --> 00:37:20.239 me having to interact with the user interface where I click around or like maybe 566 00:37:20.239 --> 00:37:22.519 I should write some code, instead of that, I can just talk to 567 00:37:22.159 --> 00:37:25.719 my quasi you know, admin of sorts and it just happens to be, 568 00:37:27.039 --> 00:37:30.119 you know, to be a large language model type interface. But behind the 569 00:37:30.159 --> 00:37:34.960 scenes, what's actually doing is something much more deterministic essentially, right, Like 570 00:37:35.039 --> 00:37:40.159 it's driving another system that really makes makes the smartness essentially work. I think, 571 00:37:40.480 --> 00:37:44.559 you know, in the context of engineering obviously, you know, get 572 00:37:44.599 --> 00:37:49.400 a copilot for example, I think does have some interesting aspects to it, 573 00:37:49.519 --> 00:37:52.599 right, and so I have not seen it fully you know, solved, 574 00:37:52.719 --> 00:37:54.960 Like I would wish it could write my test for me, right, Like 575 00:37:55.159 --> 00:37:58.639 when I write code, I hate writing tests, Like it's just like I'm 576 00:37:58.719 --> 00:38:00.920 lazy, and so what if I could just have copilot right it? But 577 00:38:01.000 --> 00:38:05.159 then the problem is intent, right because like it doesn't replace the intent, 578 00:38:05.280 --> 00:38:07.960 like you have to still tell it do this, do that, create that, 579 00:38:07.480 --> 00:38:10.480 But it does kind of take a little bit of the activation energy away, 580 00:38:10.519 --> 00:38:14.280 right. Sometimes when you you have a tedosnask, which there's a lot 581 00:38:14.320 --> 00:38:16.280 of things to do. It's just hard to get started. And so what 582 00:38:16.320 --> 00:38:19.599 I've heard from at least other people, and I have some seem to live 583 00:38:19.599 --> 00:38:22.280 with myself, is that the that's today already a value that you know, 584 00:38:22.360 --> 00:38:25.320 something like copilot can deliver. And so I think if we you know, 585 00:38:25.400 --> 00:38:30.920 project forward, right, I don't think the I don't think the thinking goes 586 00:38:30.960 --> 00:38:32.360 away, right, I don't think like none of the large language models are 587 00:38:32.400 --> 00:38:37.079 thinking, right, They're not reasoning, they're just like generating. And so 588 00:38:37.320 --> 00:38:44.280 I think really it's a question of how do we, like it's a question 589 00:38:44.360 --> 00:38:45.360 of like how do we drive these systems? Right, Like, how do 590 00:38:45.480 --> 00:38:52.480 we as operators as engineers drive a system in a way that makes predictable outcomes 591 00:38:52.960 --> 00:38:57.679 but automates the things that are you know, either hard to like it's just 592 00:38:57.960 --> 00:39:00.840 like take a lot of time. They you know, we take a lot 593 00:39:00.840 --> 00:39:02.320 of expertise, right, So I think there's a lot of opportunities there. 594 00:39:02.599 --> 00:39:07.719 But I don't think the human goes away that drives essentially this is how the 595 00:39:07.760 --> 00:39:13.320 system should work for sure. Gotcha. So there's it's a way to provide 596 00:39:13.360 --> 00:39:20.039 the technical expertise, but you still have to apply like the the is this 597 00:39:20.199 --> 00:39:23.320 a good idea, yeah, or like the bounds of it, right, 598 00:39:23.599 --> 00:39:27.559 Like maybe it gives you suggestions that Like it's kind of like we do with 599 00:39:27.599 --> 00:39:29.559 findext thing, right, So like today if I look at our solution for 600 00:39:29.639 --> 00:39:30.599 the next thing, it's okay, like it could definitely better, right, 601 00:39:30.639 --> 00:39:32.960 Like, it gives you a reasonable good recommendation. But I think over the 602 00:39:34.079 --> 00:39:36.280 years, but I'll see you know us do right, It's like at PG 603 00:39:36.320 --> 00:39:39.000 analyzed, our index recommendation will actually get to the point where ninety percent of 604 00:39:39.039 --> 00:39:42.960 the time you they are just good, right, Like there's something that an 605 00:39:43.000 --> 00:39:45.960 expert would give you as well, and you know you can just apply them. 606 00:39:45.239 --> 00:39:50.920 But still I think the decision of when to apply them, how often 607 00:39:50.960 --> 00:39:52.320 to apply them, you know, which level of testing to do, that 608 00:39:52.480 --> 00:39:59.000 is something that a human operator should essentially take into accounts and decide because I 609 00:39:59.079 --> 00:40:01.519 think otherwise, you know, otherwise, you know, you don't really have 610 00:40:01.599 --> 00:40:04.840 control over the system, I guess, right, like you'll have you know, 611 00:40:04.920 --> 00:40:07.480 things be unnecessarily expensive and it could be cheaper you maybe have you know, 612 00:40:07.599 --> 00:40:10.639 things be slow because the system oftimised for the wrong thing. And so 613 00:40:10.679 --> 00:40:15.679 I think that there's this level of control that I anticipate us needing ever so 614 00:40:15.960 --> 00:40:19.079 you know, ever more so in the next couple of years. Yeah, 615 00:40:19.119 --> 00:40:22.119 it makes me think of the Jurassic Park meme with I think it's Jeff Goldbloom, 616 00:40:22.119 --> 00:40:25.800 where it's like you were so focused on whether or not you could you 617 00:40:25.920 --> 00:40:30.079 never stop to think whether or not you should. Yes, Yes, that's 618 00:40:30.119 --> 00:40:34.360 definitely something I think of when I see some of these things Aye does. 619 00:40:35.280 --> 00:40:45.760 Right, So what are the what are the big problems that beyond index and 620 00:40:45.920 --> 00:40:51.199 query tuning. What are some of the big problems you see with postgrass that 621 00:40:52.719 --> 00:40:59.360 fall into the I wish I'd known that sooner category? Yeah, good question. 622 00:41:01.920 --> 00:41:08.320 I think it's I mean, there are some things like most the other 623 00:41:08.360 --> 00:41:12.519 about this. So if you have a lot of data, like terabytes of 624 00:41:12.599 --> 00:41:15.000 data, you can definitely sort it in post ris, right, So like 625 00:41:15.199 --> 00:41:17.840 postcris doesn't really have a limit per se. I think the one thing that 626 00:41:17.920 --> 00:41:22.719 I've I have definitely seen is if you anticipate, you know, scaling hugely 627 00:41:22.800 --> 00:41:25.039 to the point that you know you'll have one hundred terabytes of data, it 628 00:41:25.159 --> 00:41:28.960 really does help to think a little bit about how you may be able to 629 00:41:29.000 --> 00:41:31.719 split up your data potentially or at least how it should be structured in databased. 630 00:41:32.519 --> 00:41:37.519 So I'll give you two different examples of represential data modeling of some sort 631 00:41:37.960 --> 00:41:40.760 is what I'm going for. So one example is back when I was cite 632 00:41:40.800 --> 00:41:45.239 of data. Right, societies is a sharting system, so you have different 633 00:41:45.400 --> 00:41:49.360 database servers essentially, and you scale your workload b adding servers, which generally 634 00:41:49.440 --> 00:41:52.960 is a very good pattern. Not a problem is if you're looking for, 635 00:41:52.400 --> 00:41:54.679 you know, a record, right, So let's say we have users. 636 00:41:54.800 --> 00:41:57.960 Well, let's see, yeah, let's say if use we have just we 637 00:41:58.039 --> 00:42:01.440 have billions of users, right, we have all these servers, right, 638 00:42:01.519 --> 00:42:05.840 and like a certain subset of our users are in each server, and so 639 00:42:05.960 --> 00:42:08.760 if you're looking for a particular let's say email, what we'd have to do, 640 00:42:08.960 --> 00:42:12.599 right is we essentially have to run a query across all these servers, 641 00:42:12.719 --> 00:42:15.559 right, which, like, the more service you have, the more complicated 642 00:42:15.639 --> 00:42:16.599 that becomes. And you can paralyze a love of that, right, But 643 00:42:16.679 --> 00:42:21.119 like essentially many a problem with you know, too many connections, and so 644 00:42:21.599 --> 00:42:24.400 like generally speaking, it's not good if you have a lot of queries that 645 00:42:24.519 --> 00:42:28.800 go across all the service. And so when you have this type of scaling 646 00:42:28.840 --> 00:42:34.000 out anticipation. One thing that I always do these days is I make sure 647 00:42:34.440 --> 00:42:37.480 that I think about how could my data potentially be sharded in the future, 648 00:42:37.559 --> 00:42:42.639 right, split up like that? And oftentimes let's say you you build a 649 00:42:42.639 --> 00:42:45.719 sales tool, right, and a sales tool has like B two B customers, 650 00:42:45.800 --> 00:42:47.239 right, so you have all these customer IDs, right, And so 651 00:42:49.239 --> 00:42:52.039 in the most native implementation, you have, you know, maybe a customer's 652 00:42:52.079 --> 00:42:54.079 table, and then you have a CRM records table and that has a customer 653 00:42:54.199 --> 00:42:57.960 D. But then maybe each record has a comment and sort of comment just 654 00:42:58.119 --> 00:43:00.920 you know, includes the record ID, but not the actual customer D because 655 00:43:00.920 --> 00:43:02.559 you're like, that's that seems duplicated, right, would I copy this you 656 00:43:02.639 --> 00:43:06.199 know, same value all over the place. And so the thing I would 657 00:43:06.199 --> 00:43:09.440 actually do if I anticipate the scale is I would actually include my customer D 658 00:43:09.559 --> 00:43:13.880 in this case, in all my tables. Because that's the one thing that 659 00:43:14.079 --> 00:43:16.639 makes it a lot easier to shart out your data is if it's very easy 660 00:43:16.719 --> 00:43:20.880 for you to say, if I have, you know, my one tear 661 00:43:20.920 --> 00:43:24.159 by table, which subset of the table belongs to each customer, and then 662 00:43:24.199 --> 00:43:27.840 when I'm going to move you know, like ten percent of my customers to 663 00:43:28.000 --> 00:43:30.320 this at a server, I can just you know, select you know, 664 00:43:30.440 --> 00:43:34.360 essentially by customer I D versus doing a very complicated joint that actually becomes quite 665 00:43:34.400 --> 00:43:37.960 expensive once you set its large. And so that's the one thing I would 666 00:43:37.000 --> 00:43:44.599 do to to anticipate scaling is to to really, you know, I think 667 00:43:44.679 --> 00:43:46.440 think of that, you know, what, what's your unit of subdivision essentially 668 00:43:46.480 --> 00:43:51.480 in your data? Is there a way to like potentially just add that ahead 669 00:43:51.480 --> 00:43:54.159 of time so that you have a better chance scaling in the future essentially with 670 00:43:54.239 --> 00:44:00.880 outbumach effort. And then the other thing again data related that I've found recently 671 00:44:01.000 --> 00:44:05.480 is just there are some tips and tricks. This is really kind of postcers 672 00:44:05.480 --> 00:44:09.079 specific. It probably applies to my SEQL to which is sometimes it makes sense 673 00:44:09.199 --> 00:44:13.960 to store data in a what seems like a less than optimal format, but 674 00:44:14.000 --> 00:44:16.159 it's actually more efficient. So the example is we store a lot of time 675 00:44:16.199 --> 00:44:20.000 serious data, and we don't use specialized time seriou data base. We use 676 00:44:20.039 --> 00:44:23.920 postcress for for storting postcress time serio data of course, right, And so 677 00:44:24.280 --> 00:44:29.000 one of the things we've recently done is we've started using a rays to store 678 00:44:29.039 --> 00:44:31.559 some of our data. And so imagine you have like a data point and 679 00:44:31.639 --> 00:44:35.280 you have you know, let's say you know, there's five different values, 680 00:44:35.320 --> 00:44:37.000 they're all in the same timestamp. And so the most simplest implantation is you 681 00:44:37.079 --> 00:44:39.920 just have you know, timestam column data point one, data two, they've 682 00:44:39.920 --> 00:44:45.079 went three hundred and four all the same time stam. So what we've done 683 00:44:45.119 --> 00:44:51.000 recently and this has like yielded a tremendous performance like well disk based efficiency, 684 00:44:51.000 --> 00:44:54.519 but also performance benefits, is we've essentially put more data points for the same 685 00:44:54.639 --> 00:45:00.880 customer in one row. Right, so the row essentially becomes like an array 686 00:45:00.920 --> 00:45:02.639 of time stems, array of data point one, a ray of data point 687 00:45:02.639 --> 00:45:06.119 two, a rady of data point three and such. And what that does 688 00:45:06.360 --> 00:45:09.480 is postgress is various mechanisms. How it you know, kind of will reduce 689 00:45:09.559 --> 00:45:13.519 overhead in this case, like it will move some things to a second or 690 00:45:13.599 --> 00:45:16.360 storage. In some cases it will and if you avoid the what's called tuople 691 00:45:16.400 --> 00:45:20.039 header, which is like the each row has like a little header that takes 692 00:45:20.119 --> 00:45:23.440 extra space. And so if for some reason you have a problem that looks 693 00:45:23.480 --> 00:45:27.599 like ours, right, then you may want to think about a rays as 694 00:45:27.639 --> 00:45:30.159 as a way to kind of build a not column storage of sorts, but 695 00:45:30.239 --> 00:45:34.000 like it's it's the kind of thing that the column storage is good at. 696 00:45:34.679 --> 00:45:37.119 But if you are in a row based stores, like postgress, arrays can 697 00:45:37.159 --> 00:45:40.480 be an interesting hack there to optimize things. And then you can just add 698 00:45:40.760 --> 00:45:45.000 time series database to the list of things that postgress can do. Exactly, 699 00:45:45.280 --> 00:45:47.280 Yeah, I guess I should you know, in completeness the stake, I 700 00:45:47.320 --> 00:45:51.320 should probably say that partitioning is what you should do first. So forget about 701 00:45:51.360 --> 00:45:52.800 the array stuff. You should partition your tables if you haven't, right, 702 00:45:52.840 --> 00:45:54.639 So, like that's the other thing, if you haven't append on the work 703 00:45:54.719 --> 00:45:58.920 up which time zer state it usually is. Just make sure you use partitions, 704 00:45:58.960 --> 00:46:02.000 because the big type pattern and progress is if you're like you're doing inserts 705 00:46:02.000 --> 00:46:06.920 and you're doing the leads and so what'sentually happens is that you create all lot 706 00:46:06.920 --> 00:46:08.840 of these dead rows versus if you have partitions, right, Like, let's 707 00:46:08.840 --> 00:46:13.559 imagine you want to keep thirty days with data, and so you insert each 708 00:46:13.639 --> 00:46:16.159 day's data into each partition and then on the thirtieth day you drop that partition. 709 00:46:16.559 --> 00:46:21.039 And so dropping a partition like a table petition is much cheaper than doing 710 00:46:21.119 --> 00:46:24.599 as elite statement across you know, millions of records in a table, gotcha, 711 00:46:24.719 --> 00:46:28.800 And then that not only is that more efficient to do, but it 712 00:46:28.960 --> 00:46:31.800 also saves you overhead when it comes time to vacuum the database. Is that 713 00:46:31.880 --> 00:46:35.760 correct? That's right exactly, because the vacuum doesn't have to do the work 714 00:46:35.800 --> 00:46:37.679 right because like, yeah, they're not dead ros, they just are. 715 00:46:38.119 --> 00:46:43.199 You just dropped the table, so right on. Excellent. Cool. Well, 716 00:46:43.719 --> 00:46:45.719 we could continue digging in on this, but I know you've got a 717 00:46:46.480 --> 00:46:50.960 meeting coming up here, so it feels like we're a good stopping point and 718 00:46:51.039 --> 00:46:53.719 then we'll get you off to your next meeting on time. But thanks for 719 00:46:53.960 --> 00:46:57.400 thanks for coming and talking about this. This has been cool, and I 720 00:46:58.000 --> 00:47:00.559 it's been insightful. I learned a lot of things about put Express that I 721 00:47:00.599 --> 00:47:05.400 didn't know despite having used it for a long time. Perfect. Yeah, 722 00:47:05.400 --> 00:47:08.760 And if anybody who's listening is interested to learn even more about Postgress, I 723 00:47:09.039 --> 00:47:13.800 host a weekly video series and YouTube called five Minutes of Postgress. So if 724 00:47:13.840 --> 00:47:15.519 you want to get you know, a little like snippet of what's new with 725 00:47:15.559 --> 00:47:19.840 Postgress each week, feel free to subscribe. To that, and I try 726 00:47:19.880 --> 00:47:22.960 to make that as useful as I can to the community. Right on. 727 00:47:22.119 --> 00:47:25.559 What's the name of that YouTube channel. It's just an a PG analysed channel, 728 00:47:25.599 --> 00:47:29.840 but okay, the name of the series is five minutes of Postgress Awesome. 729 00:47:30.000 --> 00:47:35.480 Right on? And then anywhere else did you hang out online that people 730 00:47:35.519 --> 00:47:39.480 can interact with you? Yeah, I mean I'm on macedon, I'm still 731 00:47:39.519 --> 00:47:45.199 on Twitter, akax and LinkedIn, so feel free to you know, find 732 00:47:45.199 --> 00:47:47.239 me online. I'll send you a few links you can include the show notes 733 00:47:47.559 --> 00:47:51.239 perfect, But generally, you know, if you want to hear more about 734 00:47:51.239 --> 00:47:53.880 PG analyes, just go through a website pglies dot com. We host webinars 735 00:47:53.920 --> 00:47:57.960 every now and then where we talk about, you know, things how how 736 00:47:58.000 --> 00:48:00.960 to running your postcress database and of course how preach olice can help. But 737 00:48:00.079 --> 00:48:04.159 we try to, you know, make that general useful. And then you 738 00:48:04.199 --> 00:48:07.559 know, also, I'm in a bunch of the postal community spaces and postals 739 00:48:07.639 --> 00:48:10.280 conferences, so if you're at a post conference later this year, maybe basically 740 00:48:10.360 --> 00:48:14.519 there awesome, right ern, Well, thank you so much for joining me 741 00:48:14.599 --> 00:48:16.440 on the show. Perfect, Thank you so much for having me all right, 742 00:48:16.679 --> 00:48:20.480 see you see everyone else Next week, by every one,