1 0:0:0,0 --> 0:0:0,48 Nik: Hello. 2 0:0:0,48 --> 0:0:0,79999995 Hello. 3 0:0:0,79999995 --> 0:0:2,24 This is Postgres.FM. 4 0:0:2,24 --> 0:0:3,9199998 My name is Nik, PostgresAI. 5 0:0:3,9199998 --> 0:0:6,3999996 As usual, my cohost is Michael pgMustard. 6 0:0:6,3999996 --> 0:0:7,36 Hi, Michael. 7 0:0:7,6 --> 0:0:8,559999 Michael: Hi, Nik. 8 0:0:8,88 --> 0:0:13,175 Nik: And today, we talk about fundamental topic, and we have returning 9 0:0:13,175 --> 0:0:16,775 guest, Radim, from BoringSQL. 10 0:0:17,095 --> 0:0:17,895 Hello, Radim. 11 0:0:17,895 --> 0:0:19,335 Thank you for coming again. 12 0:0:20,375 --> 0:0:21,095 Radim: Hello, guys. 13 0:0:21,095 --> 0:0:21,654999 Hello, Nik. 14 0:0:21,654999 --> 0:0:22,455 Hello, Michael. 15 0:0:22,455 --> 0:0:23,175 Michael: Hey, Radim. 16 0:0:23,175 --> 0:0:23,974998 Good to have you. 17 0:0:23,974998 --> 0:0:27,529999 Nik: I remember we had very interesting discussion, and you 18 0:0:27,529999 --> 0:0:31,05 obviously have interesting points of view. 19 0:0:31,05 --> 0:0:35,85 So this topic, you recently published an article, and it was 20 0:0:35,85 --> 0:0:39,129997 broadly discussed in community on Hacker News Everywhere. 21 0:0:39,61 --> 0:0:40,89 Let's start somewhere. 22 0:0:40,89 --> 0:0:44,705 Like, what caused writing this material? 23 0:0:46,065002 --> 0:0:46,465 Radim: Okay. 24 0:0:46,465 --> 0:0:49,025 That's a very good question because I'm not sure if you know 25 0:0:49,025 --> 0:0:53,105 it, but I published a series about Postgres internals. 26 0:0:53,505 --> 0:0:56,13 And that wasn't that's on arrival. 27 0:0:56,13 --> 0:1:0,85 I think there is a audience that reads it, but the real feedback 28 0:1:0,85 --> 0:1:3,09 I'm getting is actually during the conferences. 29 0:1:3,09 --> 0:1:7,49 So I think I've decided to write this article during the PG DATA 30 0:1:7,49 --> 0:1:13,115 in Chicago because I'm actually doing the visualizing Postgres 31 0:1:13,195 --> 0:1:14,715004 internals series. 32 0:1:14,715004 --> 0:1:18,555 And this is where most of the interesting ideas and interesting 33 0:1:18,555 --> 0:1:19,595 question happens. 34 0:1:19,995 --> 0:1:24,955 And many questions because people on those conferences are Oracle 35 0:1:24,955 --> 0:1:28,68 practitioners now switching to Postgres even if they some of 36 0:1:28,68 --> 0:1:33,16 them won't, some of them are not so keen, and they ask very uncomfortable 37 0:1:33,16 --> 0:1:33,96 questions. 38 0:1:34,04 --> 0:1:37,32 Very uncomfortable in a way why it's built this way. 39 0:1:37,8 --> 0:1:41,665 And then I'm also working with other database systems. 40 0:1:41,665 --> 0:1:44,945 I'm not actually like a Oracle DBA, but I work a lot over the 41 0:1:44,945 --> 0:1:47,025 SQL Server, Informix. 42 0:1:47,104996 --> 0:1:48,145 I do a lot of things. 43 0:1:48,305 --> 0:1:51,425 So people who I deal with, they ask me the same questions. 44 0:1:51,425 --> 0:1:51,745 Why? 45 0:1:51,745 --> 0:1:52,784996 Why it happened? 46 0:1:53,185 --> 0:1:57,96 And the final straw was a friend of mine who went to some unrelated 47 0:1:57,96 --> 0:2:2,04 database event and he was just sending me slides how non Postgres 48 0:2:2,04 --> 0:2:7,895 companies are blaming Postgres for MVCC And I was like, there's 49 0:2:7,895 --> 0:2:8,77501 no response. 50 0:2:9,255 --> 0:2:16,055 So my goal was actually write a piece that will say there is 51 0:2:16,055 --> 0:2:17,255 nobody to blame. 52 0:2:17,495 --> 0:2:19,575 And I hope that message actually got across. 53 0:2:19,575 --> 0:2:21,54 I was actually surprised about the reception. 54 0:2:21,54 --> 0:2:22,66 That's the other thing. 55 0:2:22,66 --> 0:2:26,66 It says the Postgres MVCC is bad, but the goal wasn't to say 56 0:2:26,66 --> 0:2:27,78001 it's the worst. 57 0:2:28,34 --> 0:2:32,5 Goal will say this is a very difficult topic, that nobody has 58 0:2:32,5 --> 0:2:36,79501 a universal answer because it all depends on your flow, and those 59 0:2:36,79501 --> 0:2:39,35501 are the examples how can it be done. 60 0:2:39,91501 --> 0:2:45,195 So actually the question is, because to both of you, you have 61 0:2:45,195 --> 0:2:49,195 experience with Postgres, so how did that article actually how 62 0:2:49,195 --> 0:2:49,99501 did you read it? 63 0:2:50,58 --> 0:2:53,06001 That's actually something that I'm curious about. 64 0:2:54,34 --> 0:2:55,70001 Michael: I can go first. 65 0:2:56,66 --> 0:3:0,1 For me, I really liked the framing. 66 0:3:0,34 --> 0:3:4,735 I think I mostly ignore titles because I know titles often 67 0:3:4,735 --> 0:3:7,05501 have to get people to read it in the first place. 68 0:3:7,05501 --> 0:3:11,53502 So I didn't feel negatively about the title, MVCC is bad. 69 0:3:11,695 --> 0:3:15,29501 I was more focused on, oh, this is really interesting. 70 0:3:15,455 --> 0:3:18,095 He's gonna actually compare it to other systems. 71 0:3:18,095 --> 0:3:23,38 And I don't think anyone's done that, at least well or in detail, 72 0:3:23,62001 --> 0:3:24,74 for a long time. 73 0:3:24,82 --> 0:3:30,18001 And I found it really interesting to think through how are they 74 0:3:30,34 --> 0:3:33,7 what are they you listed four big kind of architectural decisions 75 0:3:33,7 --> 0:3:38,655 and listed how several database systems had made different trade 76 0:3:38,655 --> 0:3:42,015 offs or chosen different strategies on each of those four axes. 77 0:3:42,175 --> 0:3:44,895 I thought that was the clearest way I've seen explained. 78 0:3:45,375 --> 0:3:48,51 I didn't agree with every one of your conclusions on what's good 79 0:3:48,51 --> 0:3:52,27 and what's bad and what should change, but I did agree with the 80 0:3:52,27 --> 0:3:54,27 premise that there are trade offs. 81 0:3:54,27 --> 0:3:57,55 When it comes to database performance and correctness and things, 82 0:3:58,75 --> 0:4:1,805 different systems have chosen different trade offs even when 83 0:4:1,805 --> 0:4:4,765 their goals are largely seem to be the same. 84 0:4:4,765 --> 0:4:9,96501 If you think about the goals of Oracle, SQL Server, Postgres, 85 0:4:10,205 --> 0:4:13,95 it's not like they're targeting fundamentally different workloads. 86 0:4:13,95 --> 0:4:16,35 It's not OLAP versus OLTPs. 87 0:4:16,91 --> 0:4:22,91 Largely OLTP systems that have much the same requirements. 88 0:4:22,91 --> 0:4:25,31 So it's I found it really interesting how different some of those 89 0:4:25,31 --> 0:4:26,75 architectural choices were. 90 0:4:26,75 --> 0:4:29,66498 And I think I knew more about the failure modes in Postgres 91 0:4:29,66498 --> 0:4:31,905 than I did in all the other systems, so I found it really interesting 92 0:4:31,905 --> 0:4:33,505 learning about some of the others. 93 0:4:34,305 --> 0:4:35,025 Nik: Yeah. 94 0:4:35,425 --> 0:4:40,80002 So in my case, I think you're touching the topic where people 95 0:4:40,80002 --> 0:4:42,80002 have pain, true pain. 96 0:4:43,36002 --> 0:4:47,92 And it's like we have had the DBOS recently and also the topic 97 0:4:47,92 --> 0:4:50,4 of implementing queues and Postgres. 98 0:4:50,4 --> 0:4:55,945 It's also, like, painful and but still, these topics, they flame 99 0:4:55,945 --> 0:5:0,42502 huge discussions because there is real pain people experience. 100 0:5:1,225 --> 0:5:1,625 Right? 101 0:5:1,625 --> 0:5:6,185 And first of all, I liked the depth and visualization piece. 102 0:5:6,185 --> 0:5:8,105 Obviously, you used the AI for it. 103 0:5:8,185 --> 0:5:8,74503 This is great. 104 0:5:8,91 --> 0:5:10,03 I like it a lot. 105 0:5:10,67 --> 0:5:15,95 And comparing to others, the I think the main thing which is 106 0:5:16,43 --> 0:5:21,55 hanging in the air is that Postgres needs multiple different 107 0:5:20,925 --> 0:5:21,72498 engines. 108 0:5:21,72498 --> 0:5:24,04498 And this is this is demand for it. 109 0:5:24,525 --> 0:5:28,285 Because this approach that we have right now, the only approach, 110 0:5:29,00497 --> 0:5:32,685 it has issues in some workloads. 111 0:5:32,76498 --> 0:5:35,32 And it's inevitable to hit those issues. 112 0:5:35,88 --> 0:5:36,52002 Right? 113 0:5:37,32 --> 0:5:38,68002 Radim: You just said it. 114 0:5:38,68002 --> 0:5:43,96002 In some workloads, we can't be comparing apples and oranges. 115 0:5:44,36002 --> 0:5:48,76498 And you I think, actually, you summarized the goal that I had. 116 0:5:48,76498 --> 0:5:51,885 I wanted only to point out there is no free lunch. 117 0:5:52,205 --> 0:5:54,845 You have to know what you and this is what I'm doing with the 118 0:5:54,845 --> 0:5:55,645 BoringSQL. 119 0:5:55,645 --> 0:5:57,805 You need to know what you're optimizing for. 120 0:5:57,805 --> 0:6:1,85 And, actually, Nik, your queue implementation is one that actually 121 0:6:1,85 --> 0:6:6,73 started the discussion because now I have to admit I was in a 122 0:6:7,21 --> 0:6:13,73502 I don't mind using Postgres, I work with them, you did actually 123 0:6:13,73502 --> 0:6:14,61502 the turnover. 124 0:6:14,61502 --> 0:6:17,33502 You changed the bloat situations into a something 125 0:6:17,73502 --> 0:6:20,215 Nik: Just in case it's not it was not me. 126 0:6:20,215 --> 0:6:22,695 I just repackaged Skype's. 127 0:6:22,77502 --> 0:6:23,33502 Okay. 128 0:6:23,33502 --> 0:6:25,495 Twenty year old implementation. 129 0:6:25,495 --> 0:6:27,95 I just repackaged it so that you can use it everywhere. 130 0:6:27,95 --> 0:6:29,87 It's very old thing. 131 0:6:30,99 --> 0:6:32,03 Just modernized. 132 0:6:32,03 --> 0:6:32,67 That's it. 133 0:6:32,67 --> 0:6:33,95 So it's not my idea. 135 0:6:33,95 --> 0:6:38,685 Michael: I also think calling it a queue is a little bit misleading. 136 0:6:38,685 --> 0:6:40,845 We talked about this a while ago, but I think it 137 0:6:40,925 --> 0:6:41,72498 Nik: Well, let's not go there. 138 0:6:41,72498 --> 0:6:45,485 Michael: But I think it's important because I think actual queues 139 0:6:45,485 --> 0:6:48,125 do need updating and things. 140 0:6:48,04498 --> 0:6:49,485 Nik: This is a I'm ready. 141 0:6:49,485 --> 0:6:50,04498 Doesn't need. 142 0:6:50,22 --> 0:6:50,54 Yeah. 143 0:6:50,54 --> 0:6:54,7 I'm ready if Brandur is okay and all maintainers of River are 144 0:6:54,7 --> 0:6:55,1 okay. 145 0:6:55,1 --> 0:6:58,7 I'm ready to swap names because this thing is actually a stream 146 0:6:58,7 --> 0:6:59,42 of events. 147 0:6:59,42 --> 0:7:1,5 It's more like a river than a queue. 148 0:7:1,66 --> 0:7:3,1 So let's swap names. 149 0:7:4,485 --> 0:7:7,685 Radim: But I think we just got right into middle of the discussion 150 0:7:7,685 --> 0:7:11,045 because just realizing the difference between queue and stream, 151 0:7:11,445 --> 0:7:14,645 you need to be able to make that distinction because otherwise 152 0:7:14,645 --> 0:7:17,60498 you will choose the bad design and you will never know what hit 153 0:7:17,60498 --> 0:7:17,845 you. 154 0:7:18,19998 --> 0:7:21,72 And from using this analogy at 3AM in the morning, you will get 155 0:7:21,72 --> 0:7:23,32 paged and you don't know what it is. 156 0:7:23,32 --> 0:7:26,84 So for me this was the case, and this is why I'm doing the Postgres 157 0:7:26,84 --> 0:7:30,6 internals, not because I would believe Postgres is the best in 158 0:7:30,6 --> 0:7:35,455 everything, I just believe for a lot of scenarios Postgres is 159 0:7:35,455 --> 0:7:38,415 a good choice and the more you know about the internals and the 160 0:7:38,415 --> 0:7:40,815 trade offs the better design you can do. 161 0:7:41,215 --> 0:7:44,175 And that's why you have to compare the different postmortems 162 0:7:44,175 --> 0:7:49,15 why Postgres didn't work for people And you can evaluate, you 163 0:7:49,15 --> 0:7:52,51 can understand what are the kind of edge cases, why it doesn't 164 0:7:52,51 --> 0:7:52,91 work. 165 0:7:52,91 --> 0:7:55,79 There are other edge cases where different database systems wouldn't 166 0:7:55,79 --> 0:7:57,94998 work for the same scenarios. 167 0:7:57,94998 --> 0:8:0,385 I think the queues is a shared topic. 168 0:8:0,625 --> 0:8:4,065 It wasn't an article, but what I actually did as part of the 169 0:8:4,065 --> 0:8:7,26498 writing, I did the research how different systems work with the 170 0:8:7,26498 --> 0:8:12,225 queues, and I actually found it's a surprising topic because 171 0:8:12,225 --> 0:8:15,00998 all of them have a support to make this happen. 172 0:8:15,16998 --> 0:8:18,13 So this is one of the things I didn't expect. 173 0:8:18,37 --> 0:8:21,49 We see it from Postgres because we are using it, we are interested 174 0:8:21,49 --> 0:8:26,53 to make it better, but I because I don't live in Oracle ecosystem, 175 0:8:26,53 --> 0:8:29,33 but they have commercial product that effectively does the same. 176 0:8:29,49 --> 0:8:32,66504 Microsoft SQL Server has a optimization for it. 177 0:8:32,66504 --> 0:8:36,185 So queues is a pattern that actually causes issues, and they 178 0:8:36,185 --> 0:8:39,22504 all have to work with it in one or another way. 179 0:8:40,34503 --> 0:8:40,985 Michael: Nice. 180 0:8:40,985 --> 0:8:44,025 On that note, I think you laid it out really nicely in the 181 0:8:44,025 --> 0:8:46,14 article with these four key areas. 182 0:8:46,14 --> 0:8:50,22003 I wondered if you wanted to lay out kind of what maybe briefly, 183 0:8:50,22003 --> 0:8:55,02 what is it what's MVCC and why are these four decisions 184 0:8:55,02 --> 0:8:55,98004 quite important? 185 0:8:56,7 --> 0:8:57,18 Radim: Okay. 186 0:8:57,18 --> 0:9:0,295 So what I'm trying to do during my sessions, I'm trying to make 187 0:9:0,295 --> 0:9:6,135 people aware that as long as you have a one consumer or producer 188 0:9:6,695 --> 0:9:9,735 and that's all you have, life is easy. 189 0:9:10,135 --> 0:9:10,375 Mhmm. 190 0:9:10,375 --> 0:9:11,975 Effectively, you do everything. 191 0:9:12,27997 --> 0:9:14,76 If you have a short transactions, there is nothing. 192 0:9:14,76 --> 0:9:17,24 I mean, you can pretty much pick any engine you want. 193 0:9:17,72 --> 0:9:22,6 When you introduce concurrency, this is where you start having 194 0:9:22,6 --> 0:9:27,485 issues because concurrency will introduce this element of doubt, 195 0:9:27,485 --> 0:9:30,525 let's call it, because not everything might end up as you're 196 0:9:30,525 --> 0:9:31,165 expecting. 197 0:9:31,325 --> 0:9:35,565 As transaction time will increase, you will be looking at the 198 0:9:35,565 --> 0:9:39,645 different versions of the data, and the longer you have and the 199 0:9:39,645 --> 0:9:41,63 bigger scale you have, the more problems you have. 200 0:9:41,63 --> 0:9:44,43 And, actually, it was something I think you, Michael, said it 201 0:9:44,43 --> 0:9:48,67 when you were reviewing the your perception of the article, and 202 0:9:48,67 --> 0:9:49,79 you mentioned this. 203 0:9:49,79 --> 0:9:53,79 If we would live in a strictly OLTP world, this wouldn't be such 204 0:9:53,79 --> 0:9:54,51 a big issues. 205 0:9:54,51 --> 0:9:58,665 But this is the thing where people are actually mixing OLAP and 206 0:9:58,665 --> 0:10:3,46497 OLTP, and they introduce the variables that actually affect all 207 0:10:3,46497 --> 0:10:3,865 this. 208 0:10:3,865 --> 0:10:9,8 So you can have an extremely scalable OLTP system up until somebody 209 0:10:9,8 --> 0:10:11,08 says, want a report. 210 0:10:11,4 --> 0:10:11,8 Sure. 211 0:10:11,8 --> 0:10:15,24 There are ways how to work around this one, but this is not what 212 0:10:15,24 --> 0:10:18,92004 everybody will do because first, it's the one report. 213 0:10:20,04004 --> 0:10:21,0 So they will say, okay. 214 0:10:21,0 --> 0:10:23,135 If will use the same database, and suddenly you have a query 215 0:10:23,135 --> 0:10:27,615 that runs for thirty minutes, two hours, every Sunday you will 216 0:10:27,615 --> 0:10:31,855 lock your, let's say, transaction horizon for hours. 217 0:10:32,095 --> 0:10:33,615 And that will cause summers. 218 0:10:33,77496 --> 0:10:41,74 So for me, the situation is to make people aware that databases 219 0:10:41,74 --> 0:10:46,3 are there to build for thousands of transactions per second. 220 0:10:46,62 --> 0:10:49,66 And in order to support this, there are trade offs. 221 0:10:49,89996 --> 0:10:54,03503 And I wouldn't call, you know, I'm not there to judge the systems. 222 0:10:54,675 --> 0:10:59,715 I think it would be actually silly to judge a four, maybe five 223 0:10:59,715 --> 0:11:3,47504 decades of research and different database lineage. 224 0:11:3,47504 --> 0:11:6,13007 I think the database lineage also plays the role. 225 0:11:6,53 --> 0:11:7,97003 So I'm not going to judge it. 226 0:11:7,97003 --> 0:11:11,17004 I'm more like, let's see how different systems work with it. 227 0:11:11,33 --> 0:11:14,69 And especially painful part is when something goes wrong, what 228 0:11:14,69 --> 0:11:15,73004 is the recovery mode? 229 0:11:15,73004 --> 0:11:19,33 So that's why I had to do the four charges. 230 0:11:20,415 --> 0:11:24,57495 I know I was receiving a lot of a lot of lame photos for charges, 231 0:11:24,57495 --> 0:11:27,535 at least how they are named, because the original versions and 232 0:11:27,535 --> 0:11:32,255 I wrote it somewhere was like Guy Ritchie's style of storytelling. 233 0:11:32,255 --> 0:11:32,89496 Because yeah. 234 0:11:32,89496 --> 0:11:34,57495 I'm not sure if you are Guy Ritchie fans. 235 0:11:34,57495 --> 0:11:38,39 I'm not a, like, a storyteller, but I love love his kind of how 236 0:11:38,39 --> 0:11:40,07 how to uncover things. 237 0:11:40,07 --> 0:11:43,83 So for me, the original version actually had four different, 238 0:11:43,83 --> 0:11:46,39 how to put it, not scenes, but, like, setups. 239 0:11:46,63 --> 0:11:48,95 And that was actually describing how it is. 240 0:11:49,03 --> 0:11:49,51 Yes. 241 0:11:49,99 --> 0:11:51,03 Nik: And then you changed it? 242 0:11:51,795 --> 0:11:52,27496 Radim: Yes. 243 0:11:52,27496 --> 0:11:53,39496 I changed it. 244 0:11:53,39496 --> 0:11:54,035 So yes. 245 0:11:54,035 --> 0:11:54,755 Nik: Why? 246 0:11:56,27496 --> 0:12:0,755 Radim: This is all separate discussion because I'm a non English 247 0:12:0,755 --> 0:12:1,39496 speaker. 248 0:12:1,39496 --> 0:12:6,62 For me, even though I love to read, I can't write the way how 249 0:12:6,62 --> 0:12:9,5 I would love to write in English. 250 0:12:9,74 --> 0:12:14,7 I spent like a decade, maybe more, getting editors, then learning 251 0:12:14,7 --> 0:12:20,045 how to do certain type of writing, now LLMs they did completely 252 0:12:20,045 --> 0:12:22,365 opposite, they send it in another direction. 253 0:12:22,605 --> 0:12:26,20496 So if you go through the subtitles, I try to experiment with 254 0:12:26,20496 --> 0:12:31,08496 it, but it's also a very touching factor for some people. 255 0:12:31,08496 --> 0:12:33,96497 If you actually go through the article, you will see how I start 256 0:12:33,96497 --> 0:12:37,86 learning how to structure, how to keep the idea flowing and 257 0:12:37,86 --> 0:12:38,18 so on. 258 0:12:38,18 --> 0:12:39,54 It's a lot of work for me. 259 0:12:40,1 --> 0:12:44,01996 And this article hit every single point. 260 0:12:44,01996 --> 0:12:45,22 I'm actually happy for it. 261 0:12:45,22 --> 0:12:46,1 I'm happy to admit. 262 0:12:46,1 --> 0:12:50,01996 It's part of my BoringSQL kind of marketing, semi marketing, 263 0:12:50,26 --> 0:12:53,795 but this one was difficult because I think there were some hateful 264 0:12:53,795 --> 0:12:58,51495 emails that arrived, even, like, saying how can I they don't 265 0:12:58,51495 --> 0:13:0,195 let the network databases? 266 0:13:0,355 --> 0:13:3,795 Effectively, they thought it's a slop, so that was actually it 267 0:13:3,795 --> 0:13:7,45 was painful at the time, but it served the purpose, So I'm actually 268 0:13:7,45 --> 0:13:8,17 happy for it. 269 0:13:8,17 --> 0:13:11,61 Nik: So those emails, they are against Postgres or against 270 0:13:11,61 --> 0:13:12,81 article or what? 271 0:13:13,37 --> 0:13:14,57 Radim: Against everything. 272 0:13:14,57 --> 0:13:18,41003 I received hate from MySQL people. 273 0:13:18,41003 --> 0:13:22,09 I received hate from people that I haven't written a single line 274 0:13:22,09 --> 0:13:25,985 in that article, I received hate that I think there was one comment 275 0:13:25,985 --> 0:13:30,065 somewhere that I can't know more than one or two database systems, 276 0:13:30,14496 --> 0:13:33,58496 which is ironic because I do work with a lot of database system. 277 0:13:33,745 --> 0:13:38,06 So for me this was I knew what I'm doing when I published the 278 0:13:38,06 --> 0:13:43,42 article, but it was the first time I faced this community response 279 0:13:43,42 --> 0:13:45,34 that was very toxic. 280 0:13:45,34 --> 0:13:47,18 Nik: This is true success, first of all. 281 0:13:47,18 --> 0:13:49,98004 If you receive such emails, it's good. 282 0:13:50,62 --> 0:13:51,02 It's good. 283 0:13:51,66504 --> 0:13:56,22504 But also community, there's no single community in open source. 284 0:13:56,305 --> 0:13:59,18506 There are, like, there are many bubbles and so on. 285 0:13:59,825 --> 0:14:0,065 So 286 0:14:0,465 --> 0:14:4,22504 Radim: But I have to say, I did not receive a single negative 287 0:14:4,22504 --> 0:14:6,065 feedback from Postgres community. 288 0:14:6,79 --> 0:14:9,67 So people most people know me. 289 0:14:9,67 --> 0:14:13,27 So I think with starts, a lot of people were able to that's why 290 0:14:13,27 --> 0:14:16,23004 I ask you, what was your perception? 291 0:14:16,39 --> 0:14:16,71 Nik: Yeah. 292 0:14:16,71 --> 0:14:21,225 Let me play negative producer role. 293 0:14:21,225 --> 0:14:25,305 I like first of all, I cannot agree with you, like, we shouldn't 294 0:14:25,305 --> 0:14:25,865 judge. 295 0:14:25,865 --> 0:14:26,825 We should judge. 296 0:14:27,46497 --> 0:14:30,825 Fresh look and I was smiling when you talk about judging because 297 0:14:30,825 --> 0:14:35,27 this literally, I have right now set up with Claude, and I say 298 0:14:35,35004 --> 0:14:40,47003 offload long running coding tasks to Codex to save on Claude 299 0:14:40,47003 --> 0:14:44,55005 capacity, but don't offload judging judging on Claude. 300 0:14:44,71 --> 0:14:46,71 So I think judging is fine. 301 0:14:46,71 --> 0:14:48,325 It's like scientific approach. 302 0:14:48,325 --> 0:14:50,005 You should doubt everything always. 303 0:14:50,005 --> 0:14:50,325 Right? 304 0:14:50,325 --> 0:14:50,885 And check. 305 0:14:50,885 --> 0:14:58,405 And why not why like, why when I realized how Postgres's MVCC, 306 0:14:58,565 --> 0:15:4,75 like, it was many years ago I realized it's like someone designed 307 0:15:4,75 --> 0:15:9,63 the system thinking rollbacks will happen more often. 308 0:15:10,02997 --> 0:15:14,185 Rollback optimistic and commit to pessimistic approach. 309 0:15:14,185 --> 0:15:17,945 Because you write to new location, not to old one. 310 0:15:18,425 --> 0:15:24,745 It means that if rollback happens, then data will be in the same 311 0:15:24,745 --> 0:15:28,665 position, which is good for, like, nothing moves. 312 0:15:28,665 --> 0:15:33,68 For example, if we used cluster command and our tuples are in 313 0:15:33,68 --> 0:15:38,88 specific order which is very good for performance, we will be 314 0:15:38,88 --> 0:15:42,88 happy if more rollbacks happen on commits because commits move 315 0:15:42,88 --> 0:15:45,615 our tuples unless it's HOT update. 316 0:15:46,33496 --> 0:15:47,055 Right? 317 0:15:47,13495 --> 0:15:48,33496 And this is weird. 318 0:15:48,33496 --> 0:15:50,01495 I realized that, well, this is weird. 319 0:15:50,01495 --> 0:15:56,33496 Isn't it better to put tuple right there and move old tuple somewhere 320 0:15:56,33496 --> 0:15:56,57495 else? 321 0:15:57,43 --> 0:15:59,27 Maintaining the layout. 322 0:15:59,99 --> 0:16:0,47 Right? 323 0:16:0,47 --> 0:16:3,51 Radim: But I will I will stop you, actually, because this is 324 0:16:3,51 --> 0:16:7,11 us discussing a what are these? 325 0:16:7,11 --> 0:16:9,685 2,026 systems for the last ten years. 326 0:16:9,685 --> 0:16:12,645 We live in a high transactional times. 327 0:16:12,645 --> 0:16:17,605 But this is the reason why when I start thinking about this one. 328 0:16:17,84503 --> 0:16:22,08 When I first came across databases, they were connected to a 329 0:16:22,08 --> 0:16:26,4 Windows or some sort of fat client, where literally when you 330 0:16:26,4 --> 0:16:31,68005 open a form, your transaction started and you did the work. 331 0:16:32,08 --> 0:16:34,88 So I think this is the fundamental difference, because this is 332 0:16:34,88 --> 0:16:37,97504 why I said the lineage and actually time is what makes difference, 333 0:16:37,97504 --> 0:16:40,935 because right now I do agree with you, we have database systems 334 0:16:40,935 --> 0:16:45,97504 which have, let's say baseline 5,000 QPS, rollbacks, unless you're 335 0:16:45,97504 --> 0:16:49,11 doing maintenance or there's an error 2XA. 336 0:16:49,19 --> 0:16:50,31 Happens rarely. 337 0:16:50,55 --> 0:16:54,55 But at the times when I started, it was like it was not 338 0:16:54,55 --> 0:16:59,26996 CRMs, ERPs, economic systems, and literally people were individual 339 0:16:59,26996 --> 0:17:2,90497 users that are holding transactions for a long time, and when 340 0:17:2,90497 --> 0:17:6,585 they did something wrong, it came to some sort of bad scenario. 341 0:17:7,5449 --> 0:17:8,105 Nik: Okay. 342 0:17:8,105 --> 0:17:13,385 I started with databases twenty five years ago, and it was HDDs, 343 0:17:13,385 --> 0:17:14,6649 no SSDs. 344 0:17:14,6649 --> 0:17:15,225 Right? 345 0:17:15,705 --> 0:17:21,04 And physical layout of makes a lot of sense, especially if it's 346 0:17:21,04 --> 0:17:25,84 rotating disk, which is sequentially reading something. 347 0:17:26,56 --> 0:17:30,88 If you start moving your with your updates all the time, system 348 0:17:30,88 --> 0:17:31,52 degrades. 349 0:17:31,52 --> 0:17:33,12 It was known long ago. 350 0:17:33,015 --> 0:17:33,495 Ago. 351 0:17:33,895 --> 0:17:34,775 Long ago. 352 0:17:34,775 --> 0:17:35,255 Alright? 353 0:17:35,255 --> 0:17:38,5349 But nevertheless, this approach was chosen. 354 0:17:39,175 --> 0:17:40,855 I just think it's a mistake. 355 0:17:41,255 --> 0:17:42,055 Simple mistake. 356 0:17:42,055 --> 0:17:48,09 People just didn't think, didn't compare pros and cons of like, 357 0:17:48,09 --> 0:17:49,21 let's just go this. 358 0:17:49,2899 --> 0:17:51,77 And we know Postgres started how it was started. 359 0:17:51,77 --> 0:17:53,8499 It was started as a research project. 360 0:17:54,01 --> 0:17:54,6499 Right? 361 0:17:55,69 --> 0:17:57,3699 And let's just go this way. 362 0:17:57,61 --> 0:17:59,3949 And now everyone is suffering. 363 0:18:0,195 --> 0:18:1,795 That's simple position. 364 0:18:1,795 --> 0:18:2,2749 Right? 365 0:18:2,995 --> 0:18:4,355 Michael: I agree with you, Nik. 366 0:18:4,355 --> 0:18:8,0349 I think and I think Radim agrees as well in terms of right now, 367 0:18:8,115 --> 0:18:12,515 in most systems we look at in a healthy state, it makes tons 368 0:18:12,515 --> 0:18:15,2899 of sense to optimize for commits over roll backs. 369 0:18:15,37 --> 0:18:20,2499 But I hadn't considered before reading Radim's article the other 370 0:18:20,25 --> 0:18:26,57 side effects of that design, like the MySQL DBAs or Oracle DBAs 371 0:18:26,57 --> 0:18:30,425 that have a runaway update query updating a lot of rows. 372 0:18:30,9851 --> 0:18:34,185 Maybe it's already begun for an hour and then they need to cancel 373 0:18:34,185 --> 0:18:35,625 it because it's causing issues. 374 0:18:35,625 --> 0:18:38,425 We've all had to cancel long running queries that are causing 375 0:18:38,425 --> 0:18:38,8251 issues. 376 0:18:38,8251 --> 0:18:39,385 Right? 377 0:18:39,7051 --> 0:18:42,5851 And then it takes just as long to cancel or it takes another 378 0:18:42,5851 --> 0:18:43,625 hour to cancel. 379 0:18:44,48 --> 0:18:47,36 That is just an issue we don't have in Postgres. 380 0:18:47,36 --> 0:18:50,48 So that's a really interesting difference. 381 0:18:50,48 --> 0:18:53,4401 Like, whilst rollbacks might be rare, when they're important, 382 0:18:53,4401 --> 0:18:54,96 they can be very important. 383 0:18:55,2001 --> 0:18:58,0801 So that was a really interesting, like, trade off that I hadn't 384 0:18:58,0801 --> 0:18:58,88 thought about before. 385 0:19:0,135 --> 0:19:2,455 Nik: This is exactly what I wanted to discuss. 386 0:19:2,455 --> 0:19:2,855 Yes. 387 0:19:2,855 --> 0:19:3,175 Michael: Okay. 388 0:19:3,175 --> 0:19:4,375 Nik: But still yeah. 389 0:19:4,375 --> 0:19:7,8151 Still I wish tuples wouldn't be moved by updates of that, 390 0:19:7,8151 --> 0:19:9,015 like, all the time. 391 0:19:9,175 --> 0:19:11,335 There's just a lot of headache all the time. 392 0:19:11,335 --> 0:19:15,39 This is why we talk about partitioning attempt to just to contain 393 0:19:15,39 --> 0:19:17,95 them to smaller places and so on. 394 0:19:17,95 --> 0:19:19,71 Partitioning is important and so on. 395 0:19:19,71 --> 0:19:21,07 But still, yeah, I understand. 396 0:19:21,07 --> 0:19:26,4299 And SQL Server also have I I've heard about headaches they 397 0:19:25,485 --> 0:19:30,125 have, which is explained by design there as well. 398 0:19:30,125 --> 0:19:30,365 Yeah. 399 0:19:30,365 --> 0:19:33,1649 So, anyway, okay. 400 0:19:33,165 --> 0:19:36,205 I have another thing to criticize your article. 401 0:19:36,205 --> 0:19:39,485 You talk about long running transactions, but somehow you forget 402 0:19:39,485 --> 0:19:43,64 about long running transactions happening on replicas on standbys 403 0:19:43,64 --> 0:19:48,4401 and abandoned logical replication slots not used to applications 404 0:19:48,4401 --> 0:19:53,5249 like catalog xmin horizon or abandoned prepared transactions 405 0:19:53,5249 --> 0:19:54,4849 and so on. 406 0:19:54,485 --> 0:19:55,0449 Right? 407 0:19:55,365 --> 0:19:58,6449 Is it just things that need to be polished in your article or 408 0:19:58,6449 --> 0:19:59,205 what? 409 0:20:0,245 --> 0:20:2,6449 Radim: I wouldn't be writing article in that case. 410 0:20:2,6449 --> 0:20:4,8049 I'll be writing book about total. 411 0:20:4,8049 --> 0:20:6,245 That's the I already have this 412 0:20:6,325 --> 0:20:9,24 Nik: I cannot agree with you because this is exactly what 413 0:20:9,24 --> 0:20:11,1599 we see with customers. 414 0:20:11,16 --> 0:20:14,36 They like, the case when you have long running transaction 415 0:20:14,36 --> 0:20:17,96 on the same server, it's like it's a simple the simplest case. 416 0:20:18,52 --> 0:20:22,775 But they hit problems when, like, everyone is playing with logical 417 0:20:22,775 --> 0:20:24,615 replication these days too much. 418 0:20:24,775 --> 0:20:25,0951 Right? 419 0:20:25,0951 --> 0:20:28,135 We just, like actually, Postgres should have something better 420 0:20:28,135 --> 0:20:29,175 in this area. 421 0:20:29,175 --> 0:20:31,5751 Like, it's abandoned slots. 422 0:20:31,5751 --> 0:20:33,495 It's headache all the time. 423 0:20:34,295 --> 0:20:38,43 And I'm proposing mentioning them in one paragraph. 424 0:20:38,43 --> 0:20:41,87 Radim: Funnily enough, because I do work on I will continue 425 0:20:41,87 --> 0:20:43,7899 with my Postgres internal series. 426 0:20:44,27 --> 0:20:47,63 And I spent a lot of on around the page, what happening on the 427 0:20:47,63 --> 0:20:48,6699 physical page. 428 0:20:48,8301 --> 0:20:52,395 The next one is the replication, the WAL, how it affects things 429 0:20:52,395 --> 0:20:53,115 like this one. 430 0:20:53,115 --> 0:20:55,755 So you see I'm building the case because I'm not looking at this 431 0:20:55,755 --> 0:21:0,075 one from a I think your position, it might be different because 432 0:21:0,0751 --> 0:21:6,075 you are effectively talking about top 1% of the edge cases. 433 0:21:6,3151 --> 0:21:10,83 What I'm talking more is the articles, not this one, but the 434 0:21:10,83 --> 0:21:16,51 internal storage internal articles are for people who don't know 435 0:21:16,51 --> 0:21:16,83 it. 436 0:21:16,83 --> 0:21:20,555 Surprisingly, a lot of people even like a staff engineer and 437 0:21:20,555 --> 0:21:23,035 architect level, they usually like that knowledge. 438 0:21:23,3551 --> 0:21:26,0751 So this is my this is my case for building such a case. 439 0:21:26,0751 --> 0:21:30,155 So I can't actually overwhelm people because if I would just 440 0:21:30,155 --> 0:21:33,435 stack everything into a one piece, people wouldn't understand. 441 0:21:33,435 --> 0:21:37,19 I even have problems, and those are not a hypothetical cases, 442 0:21:37,27 --> 0:21:40,5499 when I read the feedback of audience during the sessions, you 443 0:21:40,5499 --> 0:21:44,7899 would be surprised how many people might be using a Postgres 444 0:21:44,7899 --> 0:21:48,655 for a decade, and they are not aware, they might not understand 445 0:21:48,655 --> 0:21:49,615 HOT updates. 446 0:21:49,615 --> 0:21:51,375 They might not understand change 447 0:21:51,535 --> 0:21:53,935 Nik: deal with them all the time, with back end engineers 448 0:21:53,935 --> 0:21:59,4551 who, like, we always try to find the language to explain difficult 449 0:21:59,4551 --> 0:22:1,375 problems in an easier way. 450 0:22:1,855 --> 0:22:5,9099 So I cannot agree with you about one percent at all. 451 0:22:5,99 --> 0:22:9,51 And moreover, I think it's like few months ago, we started this 452 0:22:9,51 --> 0:22:13,59 discussion on this very podcast with Michael that it's misleading 453 0:22:13,59 --> 0:22:16,87 to say long running transactions are harmful. 454 0:22:17,43 --> 0:22:20,405 Your actually, your article explains it. 455 0:22:20,405 --> 0:22:23,2051 Repeatable read versus read committed. 456 0:22:23,2051 --> 0:22:25,285 Read committed shifts xmin horizon. 457 0:22:25,285 --> 0:22:25,605 Right? 458 0:22:25,605 --> 0:22:27,365 If it's like statement level. 459 0:22:27,4451 --> 0:22:30,245 While statement lasts, xmin horizon is blocked. 460 0:22:30,245 --> 0:22:32,405 Statement finished, we switched. 461 0:22:32,405 --> 0:22:33,2051 So shifted. 462 0:22:33,2051 --> 0:22:33,4451 Right? 463 0:22:33,84 --> 0:22:37,52 So saying, oh, what happened? 464 0:22:37,52 --> 0:22:38,5599 You have a lot of block. 465 0:22:38,5599 --> 0:22:40,2399 Maybe you have long running transactions. 466 0:22:40,64 --> 0:22:44,48 We heard about these decades, and I'm trying to say, like, we 467 0:22:44,48 --> 0:22:46,08 should just stop saying that. 468 0:22:46,48 --> 0:22:49,265 And we should start we should introduce xmin horizon concept 469 0:22:49,265 --> 0:22:50,0651 to everyone. 470 0:22:50,0651 --> 0:22:53,5851 I know it's, like, maybe not trivial, but saying long running 471 0:22:53,5851 --> 0:22:56,625 transaction is the, like, wrong thing completely. 472 0:22:57,3451 --> 0:23:0,16 Radim: I do understand what you're saying, but I would still 473 0:23:0,16 --> 0:23:3,92 I would still challenge it on understanding because if we said 474 0:23:3,92 --> 0:23:8,4 about HOT updates, okay, this is Postgres specifics, I'm not 475 0:23:8,4 --> 0:23:11,52 very optimistic about actually people understanding the transaction 476 0:23:11,52 --> 0:23:12,2401 isolation. 477 0:23:12,2401 --> 0:23:13,2001 That's the other thing. 478 0:23:13,365 --> 0:23:14,965 I'm just working with what I have. 479 0:23:14,965 --> 0:23:21,525 What I hear is we can have a discussion, and the humble part 480 0:23:21,525 --> 0:23:25,605 is I wouldn't actually say bad decision back then. 481 0:23:25,765 --> 0:23:32,5499 I think decisions that were made, and we're paying tax of it. 482 0:23:33,51 --> 0:23:39,1901 We can optimize it by understanding, but we need people who don't 483 0:23:39,1901 --> 0:23:41,43 have full understanding to work much better with it. 484 0:23:41,43 --> 0:23:44,525 Because you can design a perfectly working system even if it 485 0:23:44,605 --> 0:23:48,205 if I would accept the premise that Postgres MVCC is really 486 0:23:48,205 --> 0:23:51,485 bad and mistakes were made, you can still work around this one 487 0:23:51,485 --> 0:23:55,085 because I think three of us, we know what are the limits, we 488 0:23:55,085 --> 0:23:58,59 would design it in that way, and this is effectively all the 489 0:23:58,59 --> 0:24:0,4299 reviews I'm doing are about the same. 490 0:24:0,4299 --> 0:24:3,47 Like, you can't do this one, do it this way. 491 0:24:3,47 --> 0:24:8,03 And then I face the people who have actually they have no interest 492 0:24:8,03 --> 0:24:9,71 in databases and they ask why. 493 0:24:10,855 --> 0:24:15,8949 So I think the balance is I'm looking at it, I'm not trying to 494 0:24:15,8949 --> 0:24:20,7749 change the world like by saying I wouldn't even dare to challenge 495 0:24:20,7749 --> 0:24:21,8949 like Postgres. 496 0:24:22,1349 --> 0:24:27,26 And I'm actually, I have stories from the hacker newsletter from 497 0:24:27,26 --> 0:24:32,38 Postgres how sometimes it's very what's the word? 498 0:24:33,18 --> 0:24:38,4601 Humbling to understand all the decisions that were made over 499 0:24:38,4601 --> 0:24:39,66 a long period of time. 500 0:24:39,66 --> 0:24:41,605 So I'm actually avoiding that area. 501 0:24:41,605 --> 0:24:45,365 I think this is the one area that I'm trying to avoid because 502 0:24:45,845 --> 0:24:49,845 it might be the same one as other rewrites, you know, AI rewrites. 503 0:24:50,3251 --> 0:24:52,405 It only needs to be proven over over time. 504 0:24:52,95 --> 0:24:56,95 I'm not saying Postgres is best, I think Postgres has a reasonable 505 0:24:56,95 --> 0:25:2,1499 default and a lot of engineering that went to most of the cases 506 0:25:2,3099 --> 0:25:3,99 if you are aware how they work. 507 0:25:5,445 --> 0:25:8,1649 So this is effectively my position. 508 0:25:9,525 --> 0:25:10,1649 Michael: Nice. 509 0:25:10,8049 --> 0:25:15,765 On the charges that you listed, which do you see affecting people 510 0:25:15,765 --> 0:25:20,645 the most, or which do you see people getting confused about the 511 0:25:20,25 --> 0:25:20,73 most? 512 0:25:20,73 --> 0:25:25,21 Radim: I think understanding versioning is there is not a one 513 0:25:25,21 --> 0:25:27,77 charge which would be most dramatic. 514 0:25:27,77 --> 0:25:30,17 I think it starts with versioning. 515 0:25:30,17 --> 0:25:34,2051 As soon as you have a multiple version of the same data or similar 516 0:25:34,2051 --> 0:25:39,805 data, people get confused over time and that's where the 517 0:25:39,805 --> 0:25:40,525 problem start. 518 0:25:40,525 --> 0:25:42,845 We are right in the middle of MVCC. 519 0:25:42,845 --> 0:25:45,8049 Versioning is actually what makes it difficult. 520 0:25:46,045 --> 0:25:49,85 We can discuss whatever it's because people don't get maybe 521 0:25:49,85 --> 0:25:52,1699 the full impact of isolation levels. 522 0:25:52,49 --> 0:25:52,73 Mhmm. 523 0:25:52,73 --> 0:25:54,8099 But this is something they have to work with. 524 0:25:55,21 --> 0:25:58,49 Specifically to Postgres, and that could be a one thing that 525 0:25:58,49 --> 0:26:3,9349 I would love to have improved from the other systems, is indexes. 526 0:26:5,4551 --> 0:26:9,295 I actually and I said I won't criticize Postgres. 527 0:26:9,295 --> 0:26:11,6951 I don't want this to be like a attack on Postgres. 528 0:26:11,6951 --> 0:26:15,615 But I don't like, you know, they are pointing to ctids. 529 0:26:15,855 --> 0:26:16,095 Michael: Mhmm. 530 0:26:16,17 --> 0:26:16,5701 Mhmm. 531 0:26:16,5701 --> 0:26:21,6901 Radim: Because index bloat is if I would say that's 70% of 532 0:26:21,6901 --> 0:26:25,4501 problems I'm dealing with in performance because index bloat 533 0:26:25,4501 --> 0:26:26,17 is there. 534 0:26:26,17 --> 0:26:30,17 And the other article, again, it's always the it's always the 535 0:26:30,17 --> 0:26:33,725 articles that are slightly touching the boundaries. 536 0:26:33,725 --> 0:26:35,325 The vacuum is lie. 537 0:26:35,805 --> 0:26:37,085 That was another one. 538 0:26:37,3251 --> 0:26:41,405 And you wouldn't believe how much how much discussions I find 539 0:26:41,405 --> 0:26:44,445 online still months after it was published. 540 0:26:44,845 --> 0:26:48,41 And there are trackers mentioning it and only people realizing 541 0:26:48,41 --> 0:26:48,89 it. 542 0:26:48,89 --> 0:26:52,01 That's why it's slow because they don't even consider there could 543 0:26:52,01 --> 0:26:53,4501 be a problem with indexes. 544 0:26:53,4501 --> 0:26:57,9299 So this is where I believe pointing at the primary key or some 545 0:26:58,0901 --> 0:27:2,605 ID which is fixed on the row is actually better designed because 546 0:27:2,605 --> 0:27:5,645 then you don't have to do if you have a over index table, which 547 0:27:5,645 --> 0:27:9,005 is common issue, you don't have to actually do maintenance of 548 0:27:9,005 --> 0:27:9,8049 all of them. 549 0:27:10,2051 --> 0:27:11,565 Nik: And updates are faster. 550 0:27:11,5651 --> 0:27:11,885 Radim: Yeah. 551 0:27:11,885 --> 0:27:13,0851 Updates are faster. 552 0:27:13,0851 --> 0:27:13,8049 Exactly. 553 0:27:13,965 --> 0:27:17,4501 Michael: In the spirit of your article, thinking about why don't 554 0:27:17,4501 --> 0:27:21,2101 we do it, there is at least one cost right every read on that 555 0:27:21,2101 --> 0:27:22,5701 index, which could be a lot. 556 0:27:22,5701 --> 0:27:22,81 Right? 557 0:27:22,81 --> 0:27:25,77 If you think about systems that have a lot of reads for every 558 0:27:25,77 --> 0:27:30,295 write, every single one of them is having to do one more hop. 559 0:27:30,295 --> 0:27:30,615 Right? 560 0:27:30,615 --> 0:27:34,295 Like, going to the logical pointer and then to the physical. 561 0:27:34,6951 --> 0:27:39,495 So there is a cost, but that cost is so low, especially nowadays. 562 0:27:39,5751 --> 0:27:42,94 It's one hop extra, and it'll always be one hop extra as far 563 0:27:42,94 --> 0:27:43,82 as I understand. 564 0:27:44,14 --> 0:27:47,98 So it's a reasonable cost and it's a fixed cost that we're willing 565 0:27:47,98 --> 0:27:50,46 to pay on every read, but there is an additional cost. 566 0:27:50,46 --> 0:27:50,7799 Radim: Yes. 567 0:27:50,7799 --> 0:27:52,2999 I think that pretty much nails it. 568 0:27:52,2999 --> 0:27:54,8749 For me, it's just as I said, I don't judge. 569 0:27:55,0349 --> 0:27:57,755 If I would have a wish list, this would be a direction. 570 0:27:57,755 --> 0:28:2,075 If we would go there, I would be happy because it would make 571 0:28:2,075 --> 0:28:7,515 a lot of people understanding systems easier and that it would 572 0:28:7,515 --> 0:28:8,875 behave as they expect. 573 0:28:8,875 --> 0:28:10,7699 Because as I said, it starts with the versioning. 574 0:28:10,7699 --> 0:28:12,69 So now you see how it's connected. 575 0:28:12,85 --> 0:28:17,57 If you pass the storage internals, you can get your head wrapped 576 0:28:17,57 --> 0:28:19,6499 around the page and how it's moved. 577 0:28:19,6499 --> 0:28:23,0099 But when the indexes come, suddenly they don't understand, and 578 0:28:23,0099 --> 0:28:26,775 then you have to start understanding one why there is a gap and 579 0:28:26,775 --> 0:28:28,775 so on, and then it goes to the HOT update. 580 0:28:28,775 --> 0:28:33,735 So certain problems can be mitigated, and again, this is my personal 581 0:28:33,735 --> 0:28:34,135 idea. 582 0:28:34,135 --> 0:28:35,575 I actually love the design. 583 0:28:35,575 --> 0:28:39,89 So if there is one point from that article and from the database 584 0:28:39,89 --> 0:28:43,97 systems I ever touch, this is the design I prefer most. 585 0:28:44,53 --> 0:28:45,1699 Michael: Mhmm. 586 0:28:45,17 --> 0:28:46,61 That makes a lot of sense. 587 0:28:47,25 --> 0:28:50,5299 Nik, if you had one thing, what would you want? 588 0:28:51,41 --> 0:28:54,9949 Nik: I would I just want I would want OrioleDB to succeed 589 0:28:55,475 --> 0:28:59,5549 so we could choose storage engines and have a lot of good stuff. 590 0:29:0,355 --> 0:29:2,6749 This would modernize Postgres a lot. 591 0:29:3,075 --> 0:29:5,235 So I'm reaching for that project a lot. 592 0:29:6,115 --> 0:29:9,71 And I keep and I keep criticizing every piece of Postgres. 593 0:29:9,71 --> 0:29:10,59 This is my nature. 594 0:29:10,59 --> 0:29:11,6299 I cannot stop. 595 0:29:12,27 --> 0:29:13,23 So yeah. 596 0:29:14,19 --> 0:29:17,5499 Michael: Just to just maybe too much of a tangent, but you brought 597 0:29:17,5499 --> 0:29:21,7749 up Oriole or OrioleDB Radim, and I wondered if you had thoughts 598 0:29:21,7749 --> 0:29:27,695 on the table access method that they that systems like that would 599 0:29:27,695 --> 0:29:29,7749 need or a new storage engine would need. 600 0:29:29,7749 --> 0:29:32,4149 Do we have enough yet in Postgres for them to succeed? 601 0:29:32,4149 --> 0:29:36,3999 Because I think Oriole still need patches for their implementation. 602 0:29:37,28 --> 0:29:42,4 And I just get the impression it's not ready for an extension 603 0:29:42,4 --> 0:29:43,6 to do it, for sure. 604 0:29:44,0 --> 0:29:45,9999 But do we know where we're up to there? 605 0:29:47,04 --> 0:29:47,84 Radim: Okay. 606 0:29:47,84 --> 0:29:48,72 I do agree. 607 0:29:49,335 --> 0:29:50,9349 Let's start with this one. 608 0:29:50,9349 --> 0:29:53,8949 Table access methods, I think it's amazing way. 609 0:29:54,855 --> 0:29:59,1749 One of the things that is worth linking to this article is this 610 0:29:59,1749 --> 0:30:3,575 Postgres in ten years presentation that was in PGConf Germany, 611 0:30:4,23 --> 0:30:5,59 and it has improvements. 612 0:30:5,59 --> 0:30:9,27 It mentions couple things like zheap, that's the project on its 613 0:30:9,27 --> 0:30:9,83 own. 614 0:30:9,83 --> 0:30:11,59 I think that's now stale anyway. 615 0:30:12,3099 --> 0:30:16,5499 But table access methods are listed as the number one improvement 616 0:30:16,5499 --> 0:30:17,5099 that made it. 617 0:30:17,91 --> 0:30:22,1951 Based on that, I thought I would be clever, and I thought I would 618 0:30:22,1951 --> 0:30:24,515 explore, but I hit the limits quite fast. 619 0:30:24,515 --> 0:30:25,955 It wasn't for anything production. 620 0:30:25,955 --> 0:30:29,555 It was just for experimenting, but I found the limits quite quite 621 0:30:29,555 --> 0:30:30,115 fast. 622 0:30:30,1951 --> 0:30:34,46 And if I'm able to do that, I think that actually is the is the 623 0:30:34,46 --> 0:30:35,02 feedback. 624 0:30:35,02 --> 0:30:40,78 Because if a developer of my kind can hit the limits, it's not 625 0:30:40,78 --> 0:30:44,2999 going to give us OrioleDB kind of level support we need because 626 0:30:44,62 --> 0:30:45,4199 there's much more. 627 0:30:45,4199 --> 0:30:47,1799 There are things that I'm probably not aware. 628 0:30:47,355 --> 0:30:49,515 I think indexes are generally problem. 629 0:30:49,515 --> 0:30:51,2749 I think they are not touched at all. 630 0:30:51,355 --> 0:30:54,5549 That was funding I had because I had some crazy idea about indexes 631 0:30:54,5549 --> 0:30:55,595 and figure What out what get 632 0:30:56,635 --> 0:30:57,7549 Nik: do you mean not touched? 633 0:30:58,475 --> 0:30:59,995 Radim: I think there was some limitation. 634 0:30:59,995 --> 0:31:2,7001 I would have to dig because it's a couple months back. 635 0:31:2,7001 --> 0:31:6,3 I played with it, I had some issues finding there was no interface 636 0:31:6,3 --> 0:31:10,14 I couldn't find in the table access method that I can use. 637 0:31:10,46 --> 0:31:11,1 Nik: Okay. 638 0:31:11,42 --> 0:31:11,9 Yeah. 639 0:31:11,9 --> 0:31:15,805 There are many improvements, like deduplication in thirteen, fourteen 640 0:31:15,805 --> 0:31:17,405 or we see these things. 641 0:31:17,405 --> 0:31:20,525 There is an ongoing Google Summer of Code projects I'm rooting 642 0:31:20,525 --> 0:31:24,605 for a lot as well, which is trying to implement merge for B-tree. 643 0:31:24,765 --> 0:31:27,565 This would solve many cases with bloat, actually. 644 0:31:28,65 --> 0:31:29,05 Michael: Yeah. 645 0:31:29,05 --> 0:31:31,37 But this is on the this is on the regular. 646 0:31:31,37 --> 0:31:34,97 This is, like, the current implementation of the heap. 647 0:31:34,97 --> 0:31:35,37 Right? 648 0:31:35,53 --> 0:31:35,9299 Yeah. 649 0:31:36,5701 --> 0:31:40,41 Nik: Many directions things are trying to happen, but it's 650 0:31:40,41 --> 0:31:42,25 there are, of course, obstacles. 651 0:31:42,81 --> 0:31:45,8049 And, yeah, it would not eliminate the problem of xmin horizon 652 0:31:45,8049 --> 0:31:49,245 being blocked and vacuum cannot delete that tuples, but merge 653 0:31:49,245 --> 0:31:54,205 in B-tree could make B-tree automatically healing after multiple 654 0:31:54,605 --> 0:31:56,1249 cycles of vacuuming. 655 0:31:56,285 --> 0:32:0,34 So because right now it can only split page and grow in size 656 0:32:0,34 --> 0:32:1,2999 and that's it. 657 0:32:1,7 --> 0:32:3,22 And not necessarily. 658 0:32:3,38 --> 0:32:7,22 Empty if in the middle of it some pages fully empty it can 659 0:32:7,22 --> 0:32:7,94 be removed. 660 0:32:7,94 --> 0:32:10,98 autovacuum will But remove if it's a little if it has little 661 0:32:11,14 --> 0:32:16,045 at least one link to a tuple, this page won't be removed. 662 0:32:16,045 --> 0:32:16,685 That's all. 663 0:32:16,685 --> 0:32:20,525 And for int8, for example, a bigserial or something. 664 0:32:20,525 --> 0:32:20,765 Right? 665 0:32:20,765 --> 0:32:25,565 Or UUIDv7 will always insert on one side. 666 0:32:25,645 --> 0:32:31,24 Like all the pages, if you delete rows, they hang a lot of empty 667 0:32:31,24 --> 0:32:31,7999 space. 668 0:32:32,2 --> 0:32:32,52 Yeah. 669 0:32:32,52 --> 0:32:37,0 And they cannot reuse this space cannot be reused. 670 0:32:37,0 --> 0:32:38,44 This is the interesting piece. 671 0:32:38,6799 --> 0:32:40,52 So reindex concurrently is inevitable. 672 0:32:40,52 --> 0:32:44,065 Also, that's great that we have Repack concurrently in Postgres 673 0:32:44,065 --> 0:32:44,5449 19. 674 0:32:44,5449 --> 0:32:44,705 Yeah. 675 0:32:44,705 --> 0:32:47,4249 Which is very big gift, think. 676 0:32:47,825 --> 0:32:49,825 And we had the episode about that. 677 0:32:50,5449 --> 0:32:54,145 Where in the end of episode I discovered it's going to happen 678 0:32:54,145 --> 0:32:54,5449 in '19. 679 0:32:54,78 --> 0:32:55,3401 Soon. 680 0:32:55,3401 --> 0:32:55,5801 Right? 681 0:32:55,5801 --> 0:32:56,5399 We didn't know. 682 0:32:57,18 --> 0:32:58,4601 I was surprised then. 683 0:32:58,4601 --> 0:33:0,86 We didn't know it will be brought to core. 684 0:33:0,86 --> 0:33:3,42 We just talked about pg_squeeze. 685 0:33:3,42 --> 0:33:3,82 Right? 686 0:33:4,14 --> 0:33:9,0751 So, anyway, OrioleDB is a very big project. 687 0:33:9,0751 --> 0:33:9,5549 Right? 688 0:33:10,1951 --> 0:33:12,995 Radim: I wouldn't say I'm rooting for it. 689 0:33:12,995 --> 0:33:14,515 I think it's exciting project. 690 0:33:14,515 --> 0:33:17,555 I think that's the word that needs to push database development 691 0:33:17,555 --> 0:33:18,275 forward. 692 0:33:19,3151 --> 0:33:22,02 And, yes, I'm very excited to see it. 693 0:33:22,02 --> 0:33:27,4601 Nik: I dig a little bit of history, how the decision was 694 0:33:27,4601 --> 0:33:33,06 made to put newer versions, new tuples to new positions. 695 0:33:33,06 --> 0:33:36,175 It was made originally in eighties. 696 0:33:36,415 --> 0:33:39,535 So there's an article, the design of post the Postgres storage 697 0:33:39,535 --> 0:33:44,975 system from '87 VLDB by Stonebraker and others. 698 0:33:45,4551 --> 0:33:49,295 And the decision was like if you maybe know the time Postgres 699 0:33:49,295 --> 0:33:51,63 had time travel capability. 700 0:33:51,63 --> 0:33:52,19 Right? 701 0:33:52,59 --> 0:33:54,99 Radim: That's what I was about to mention. 702 0:33:54,99 --> 0:33:57,7899 That logic because And that Yeah. 703 0:33:58,27 --> 0:34:0,59 Nik: Look, follow my hands, so to speak. 704 0:34:0,6699 --> 0:34:4,35 So the trick was the idea was let's not have WAL. 705 0:34:5,375 --> 0:34:7,135 Nothing to undo, nothing to redo. 706 0:34:7,135 --> 0:34:11,135 They just keep everything, and then vacuum was born as a 707 0:34:11,5352 --> 0:34:12,735 as an archiver. 708 0:34:13,295 --> 0:34:13,695 Right? 709 0:34:13,695 --> 0:34:21,47 And then it stayed like there until in 1999, Vadim proposed and 710 0:34:21,47 --> 0:34:25,55 implemented a change to get rid of table level lock because there 711 0:34:25,55 --> 0:34:27,07 was a table level lock. 712 0:34:27,23 --> 0:34:32,91 So table level lock was removed and the concept of snapshots 713 0:34:32,91 --> 0:34:34,27 of data was introduced. 714 0:34:34,995 --> 0:34:39,7952 And a couple of years later, WAL was implemented by Vadim. 715 0:34:40,8352 --> 0:34:44,435 So now we have and then the time travel was removed. 716 0:34:44,435 --> 0:34:46,0352 This capability was removed. 717 0:34:46,0352 --> 0:34:51,1501 Now we have a piece of thing which was designed to not to have 718 0:34:51,1501 --> 0:34:52,6702 of WAL. 719 0:34:52,6702 --> 0:34:53,07 Right? 720 0:34:53,07 --> 0:34:56,03 But we fall in snapshots and everything. 721 0:34:56,11 --> 0:34:58,19 This is very interesting evolution. 722 0:34:58,19 --> 0:34:58,4302 Right? 723 0:34:59,9048 --> 0:35:1,265 And we have all the rights. 724 0:35:1,265 --> 0:35:4,1448 And my position is we have all the rights and many people have 725 0:35:4,1448 --> 0:35:7,585 all the rights to criticize this state. 726 0:35:7,825 --> 0:35:12,4648 But also, it's obvious that it's extremely hard to implement 727 0:35:12,4648 --> 0:35:18,68 new approach in the life rapidly evolving system, has releases 728 0:35:18,68 --> 0:35:19,6401 every year. 729 0:35:19,8 --> 0:35:24,84 And then also EnterpriseDB attempt zheap was not succeeded 730 0:35:25,16 --> 0:35:30,425 hasn't succeeded, right, in this to implement a new storage. 731 0:35:31,225 --> 0:35:31,5452 Yeah. 732 0:35:31,5452 --> 0:35:35,5452 But anyway, we I think people have all the rights to desire the 733 0:35:35,5452 --> 0:35:37,145 choice inside Postgres. 734 0:35:37,145 --> 0:35:40,105 Because, actually, the people who desire the choice, they want 735 0:35:40,105 --> 0:35:42,32 to stay inside Postgres usually. 736 0:35:42,32 --> 0:35:42,6401 Right? 737 0:35:42,6401 --> 0:35:44,72 They like everything else around. 738 0:35:45,68 --> 0:35:46,32 Right? 739 0:35:46,6401 --> 0:35:50,0 Radim: So And I'm actually happy that you mentioned it because 740 0:35:50,0 --> 0:35:56,095 for me this is the lineage, database lineage, where we came from, 741 0:35:56,4949 --> 0:35:58,015 how we got to that decision. 742 0:35:58,015 --> 0:36:0,815 That's why I mentioned those systems like different transaction 743 0:36:0,815 --> 0:36:4,4148 profiles and everything, because for me those are decisions that 744 0:36:4,4148 --> 0:36:5,935 were made over time. 745 0:36:6,4148 --> 0:36:10,45 I think I mentioned it I'm not sure, but I'm mentioning it quite 746 0:36:10,45 --> 0:36:11,01 often. 747 0:36:11,01 --> 0:36:15,17 For me, the painful scenario, because my official title when 748 0:36:15,17 --> 0:36:19,89 I'm presenting myself on the conferences, is skeptic turned believer. 749 0:36:20,05 --> 0:36:24,905 I was the guy who destroyed databases because even Postgres, 750 0:36:24,905 --> 0:36:26,1052 I mean, Nik said it. 751 0:36:26,185 --> 0:36:29,465 Spinning disk, you need to shut down something, and it writes 752 0:36:29,465 --> 0:36:30,2651 and writes. 753 0:36:30,2651 --> 0:36:33,705 You hear that loud noise of spinning disk writing something, 754 0:36:34,105 --> 0:36:37,6099 or you're hitting that query, killing, doing a rollback, and 755 0:36:37,6099 --> 0:36:39,29 it needs to write a lot of data. 756 0:36:40,3298 --> 0:36:45,6099 And funniest thing is actually the change is a difficult one. 757 0:36:45,6099 --> 0:36:50,185 So people from the SQL Server, they actually this is not something 758 0:36:50,185 --> 0:36:54,185 I know, but they actually faced the same problem because they 759 0:36:54,185 --> 0:36:56,905 had a problem with the tempdb, I think it's called. 760 0:36:57,865 --> 0:37:0,745 So it ran out of disk space because there was simply nothing. 761 0:37:0,69 --> 0:37:0,93 Nothing. 762 0:37:0,93 --> 0:37:6,29 So they spent actually, Microsoft did an investment on ADR, if 763 0:37:6,29 --> 0:37:7,5698 I'm mentioning it correctly. 764 0:37:7,5698 --> 0:37:13,5698 So that was that was 2,019, and it's actually a accelerated database 765 0:37:13,5698 --> 0:37:14,37 recovery. 766 0:37:14,53 --> 0:37:19,425 And what they did behind the scene is they also introduced something 767 0:37:19,425 --> 0:37:23,905 like a BayQ, because what they needed to do is move where the 768 0:37:23,905 --> 0:37:27,905 data for the log are stored, so it's now on the tablespace, 769 0:37:27,905 --> 0:37:31,04 it's not a different one, so we can go back to a tablespace 770 0:37:31,04 --> 0:37:33,28 discussion behind the different databases. 771 0:37:33,6802 --> 0:37:37,84 Even today in Postgres and Oracle, I'm not sure about other systems, 772 0:37:37,84 --> 0:37:40,24 you can work and optimize a lot about tablespaces. 773 0:37:40,595 --> 0:37:44,9949 But Microsoft had to do actually a lot of engineering work to 774 0:37:44,9949 --> 0:37:45,635 get this one. 775 0:37:45,635 --> 0:37:48,755 So that's why I'm saying I'm disagreeing and agreeing with you 776 0:37:48,755 --> 0:37:49,795 at the same time. 777 0:37:50,9148 --> 0:37:53,79 It's extremely difficult to do so. 778 0:37:54,11 --> 0:37:58,59 I can't even imagine how all the core committers find agreement 779 0:37:58,59 --> 0:38:0,35 on doing things like this one. 780 0:38:0,35 --> 0:38:3,79 Postgres is decentralized project and I still don't know how 781 0:38:3,79 --> 0:38:4,27 they do it. 782 0:38:4,8052 --> 0:38:7,445 Like, how they find that agreement, that's one thing. 783 0:38:7,7651 --> 0:38:12,485 But the point I'm trying to make is, you just said it, we've 784 0:38:12,485 --> 0:38:16,645 been through a series of designs and a lot of difficult choices 785 0:38:16,645 --> 0:38:19,205 we made, but that's also case for the other systems. 786 0:38:19,205 --> 0:38:24,57 So everybody is trying to fight, and if there was one goal of 787 0:38:24,57 --> 0:38:27,61 that article was saying, literally, there's no free lunch. 788 0:38:27,61 --> 0:38:29,85 You have to understand all the moving systems. 789 0:38:29,85 --> 0:38:33,465 I'm now playing with the MLOG on Oracle. 790 0:38:33,785 --> 0:38:41,065 It's also not a free lunch because you move a load to producer, 791 0:38:41,4648 --> 0:38:44,905 so you effectively hit the application with that cost. 792 0:38:45,305 --> 0:38:49,8699 We can go another article I'm still working on is views, materialized 793 0:38:49,8699 --> 0:38:51,23 views, all this. 794 0:38:51,47 --> 0:38:55,39 And there is always so many different different aspects that 795 0:38:55,39 --> 0:38:58,75 needs to be considered, and this is why I'm not trying to judge. 796 0:38:58,75 --> 0:39:2,175 So if you ever read something that I'm judging, I don't mean 797 0:39:2,175 --> 0:39:7,7751 judging the AI output, for me, it's always the humbling history. 798 0:39:7,7751 --> 0:39:13,48 So that's why I agree and disagree with you at the same time. 799 0:39:13,48 --> 0:39:17,7202 So I believe Postgres has a chance to improve. 800 0:39:18,28 --> 0:39:19,1602 It will improve. 801 0:39:19,1602 --> 0:39:20,36 Projects will improve. 802 0:39:20,6 --> 0:39:25,6401 I actually love how Postgres is able to not be ready for one 803 0:39:25,6401 --> 0:39:31,765 change year one, and then year plus four, five, you suddenly 804 0:39:31,765 --> 0:39:35,525 have the technology available and still the design decisions 805 0:39:35,525 --> 0:39:38,565 that were made long time ago, they still apply more or less. 806 0:39:38,565 --> 0:39:40,75 So I'm actually trying to find us a balance. 807 0:39:40,75 --> 0:39:46,11 That's why I said I wouldn't ever criticize that decision. 808 0:39:46,11 --> 0:39:47,1501 Decisions were made. 809 0:39:47,1501 --> 0:39:49,07 And that's the story for me. 810 0:39:49,3901 --> 0:39:50,35 Nik: So I agree. 811 0:39:50,35 --> 0:39:56,3352 There's no free lunch, but also I want variety of lunches. 812 0:39:57,5352 --> 0:39:58,495 I 813 0:39:59,455 --> 0:40:0,0952 Radim: do agree. 814 0:40:0,0952 --> 0:40:3,135 I would just add because the previous episode I was on this podcast 815 0:40:3,135 --> 0:40:7,2952 was RegreSQL and that for me I'm still working on it, by the 816 0:40:7,2952 --> 0:40:7,615 way. 817 0:40:7,615 --> 0:40:11,05 Just the learnings I'm getting to understand, sometimes it happens 818 0:40:11,05 --> 0:40:13,29 on the post in the hacker newsletter. 819 0:40:14,41 --> 0:40:18,01 I just the amount of decision and the knowledge that goes through 820 0:40:18,01 --> 0:40:24,01 committers' heads is actually amazing wealth of knowledge that 821 0:40:24,0898 --> 0:40:28,305 because I've learned not to act on questioning, but they usually 822 0:40:28,305 --> 0:40:31,585 convince me they know why it was made and I need to respect their 823 0:40:31,585 --> 0:40:32,065 decision. 824 0:40:32,065 --> 0:40:33,905 So this is effectively my background. 825 0:40:35,345 --> 0:40:37,745 Nik: What are your next plans in this direction? 826 0:40:37,745 --> 0:40:41,0698 Like you said you said you are working on internals. 827 0:40:41,0698 --> 0:40:42,51 You plan to visualize more. 828 0:40:42,51 --> 0:40:42,75 Right? 829 0:40:42,75 --> 0:40:47,15 Try to present internals of Postgres in a new way and so on. 830 0:40:47,15 --> 0:40:50,51 And what's the plan overall in this area? 831 0:40:51,2048 --> 0:40:54,885 Radim: Overall plan is expanding the understanding because 832 0:40:54,885 --> 0:40:59,605 I think people still need a simple way how to understand. 833 0:40:59,605 --> 0:41:2,405 I actually love the simplicity kind of. 834 0:41:2,4849 --> 0:41:5,9102 But for me, this is, like, different approach. 835 0:41:6,47 --> 0:41:10,71 So while I like it, I don't imagine showing this one to a random 836 0:41:10,71 --> 0:41:12,31 attendee of my sessions. 837 0:41:12,39 --> 0:41:12,95 They would just 838 0:41:13,03 --> 0:41:13,99 Nik: Simple already. 839 0:41:13,99 --> 0:41:14,23 Yeah. 840 0:41:14,23 --> 0:41:14,8699 It's not simple. 841 0:41:14,8699 --> 0:41:16,39 Radim: It's not simple. 842 0:41:16,39 --> 0:41:17,165 That's the thing. 843 0:41:17,165 --> 0:41:21,165 I still try to make things boring and reliable. 844 0:41:21,165 --> 0:41:26,045 AI is playing big role, so I do a lot of work on that harness 845 0:41:26,045 --> 0:41:26,7651 level. 846 0:41:27,2449 --> 0:41:31,405 So, for example, one thing, just to mention this one, outside 847 0:41:31,405 --> 0:41:34,94 of commercial things, the RegreSQL I'm trying to and I'm actively 848 0:41:34,94 --> 0:41:39,9 testing for now a couple months, a regression harness for Postgres 849 0:41:39,9 --> 0:41:40,62 itself. 850 0:41:41,0999 --> 0:41:45,02 It found one bug before it was it was merged. 851 0:41:45,0999 --> 0:41:46,3 That's the one of the things. 852 0:41:46,3 --> 0:41:50,675 When you get to commitfest level of reviews. 853 0:41:51,395 --> 0:41:55,075 I'm running, that suite, but I'm usually finding false positives, 854 0:41:55,075 --> 0:41:57,395 so this is where I'm still working in. 855 0:41:57,395 --> 0:42:1,395 I'm still very deep into the statistics ecosystem and how to 856 0:42:1,395 --> 0:42:2,3552 enrich it. 857 0:42:2,7551 --> 0:42:6,41 I have some new ideas how to make the whole regression testing 858 0:42:6,49 --> 0:42:11,29 faster, but effectively for me, I found out that this is such 859 0:42:11,29 --> 0:42:15,45 a difficult topic, we can discuss, but to get adoption even for 860 0:42:15,45 --> 0:42:18,65 open source tool is actually very difficult. 861 0:42:18,65 --> 0:42:23,935 So I actually took a detour and I'm working on I have an MCP 862 0:42:23,935 --> 0:42:28,5752 called DryRun, which finds with other MCPs, which is not the 863 0:42:28,5752 --> 0:42:29,1353 point. 864 0:42:29,215 --> 0:42:33,82 The full circle is actually to make people get the setup, 865 0:42:33,82 --> 0:42:36,78 they can actually do the regression testing and actually get 866 0:42:37,82 --> 0:42:43,5 LLMs producing code that is judged not by LLMs, but having more 867 0:42:43,5 --> 0:42:44,78 predictable output. 868 0:42:45,02 --> 0:42:46,78 But this is a personal project of mine. 869 0:42:46,995 --> 0:42:50,5952 Otherwise, the education still stays, so I'm expanding. 870 0:42:51,5552 --> 0:42:56,675 And I'm preparing I think I have now 11 articles in words because 871 0:42:56,675 --> 0:42:59,1553 I changed my writing model. 872 0:42:59,5552 --> 0:43:2,91 Because, like, when I started, I didn't know how to write for 873 0:43:2,91 --> 0:43:3,31 a blog. 874 0:43:3,31 --> 0:43:7,63 So it was like all energy into a one blog post and then I published 875 0:43:7,63 --> 0:43:10,03 something that didn't have a structure and everything. 876 0:43:10,19 --> 0:43:13,95 Now I have to if I have idea, I do some writing, then I leave 877 0:43:13,95 --> 0:43:18,9053 it, I come back to it, and I'm trying to avoid kind of the structure. 878 0:43:19,0652 --> 0:43:23,8652 So actually, the I actually had to redo some of the parts of 879 0:43:23,8652 --> 0:43:27,385 website because now you see, like, there's an internal guide 880 0:43:27,385 --> 0:43:28,665 that actually lists chapters. 881 0:43:28,74 --> 0:43:32,26 It looks like more like a book, and that's why I said, I know 882 0:43:32,26 --> 0:43:37,3801 what's the cost of writing a ever expanding articles. 883 0:43:37,86 --> 0:43:40,5 Believe me, I have one article which will go live. 884 0:43:40,5 --> 0:43:44,02 It's not educational one, and it's already read time about forty 885 0:43:44,02 --> 0:43:46,125 five minutes, I can't cut it down. 886 0:43:46,125 --> 0:43:49,645 So this is actually stuff we are talking about, and it's about 887 0:43:49,645 --> 0:43:53,0051 four months of work, which so, yeah, what I'm working on. 888 0:43:53,565 --> 0:43:54,365 Nik: Cool. 889 0:43:54,365 --> 0:43:54,925 Cool. 890 0:43:55,965 --> 0:43:56,685 Okay. 891 0:43:56,685 --> 0:43:57,3252 Good. 892 0:43:57,485 --> 0:43:58,89 Michael: That sounds amazing. 893 0:43:58,89 --> 0:44:0,01 That sounds exciting. 894 0:44:0,01 --> 0:44:3,45 I can't promise I'm gonna read the 45 one, but I will definitely 895 0:44:3,45 --> 0:44:4,25 try. 896 0:44:5,05 --> 0:44:7,53 But, yeah, it's always fun reading what you put out, and thanks 897 0:44:7,53 --> 0:44:9,77 for fighting the good fight on the education front. 898 0:44:9,77 --> 0:44:11,8706 So, yeah, thanks for coming on as well. 899 0:44:11,9504 --> 0:44:13,8706 Radim: Thanks you for having me again. 900 0:44:14,3503 --> 0:44:15,3904 Nik: Have a great week. 901 0:44:15,3904 --> 0:44:15,8704 Bye. 902 0:44:15,8704 --> 0:44:16,1904 Radim: Okay. 903 0:44:16,1904 --> 0:44:16,9104 You too.