1 00:00:00,049 --> 00:00:04,710 Hello, and welcome to Postgres FM a weekly show about all things PostgreSQL. 2 00:00:04,970 --> 00:00:06,600 I'm Michael founder of pgMustard. 3 00:00:06,620 --> 00:00:09,440 And this is my co-host Nikolay founder of Postgres AI. 4 00:00:09,860 --> 00:00:10,250 Hey Nikolay. 5 00:00:10,340 --> 00:00:11,059 How are you doing today? 6 00:00:11,450 --> 00:00:11,809 Hello. 7 00:00:11,809 --> 00:00:12,349 Doing great. 8 00:00:12,355 --> 00:00:17,360 Just returned to California from a long trip, long flight but doing great. 9 00:00:17,360 --> 00:00:17,779 How are you? 10 00:00:18,680 --> 00:00:23,570 I am also well just recovering from our hottest day ever in the UK yesterday. 11 00:00:23,711 --> 00:00:27,931 I, I was tired of movies and tried to watch some news and so on. 12 00:00:27,931 --> 00:00:34,621 And the BBC 95% of time was talking about this weather records. 13 00:00:34,681 --> 00:00:34,891 Right. 14 00:00:34,891 --> 00:00:36,421 So yeah. 15 00:00:36,901 --> 00:00:37,351 Wonderful. 16 00:00:37,351 --> 00:00:39,241 So today you chose the topic. 17 00:00:39,301 --> 00:00:41,461 What is it we're gonna be talking about and why? 18 00:00:41,956 --> 00:00:50,216 We are going to talk about, various kinds of indexes, particularly we are talking like BRIN indexes, so, block range, indexes. 19 00:00:51,066 --> 00:00:55,276 Because recently we had a few materials published, like it's, I think it's good. 20 00:00:55,546 --> 00:00:57,226 Also discussion on Hacker News. 21 00:00:57,226 --> 00:01:02,776 So it's a good time probably to discuss various aspects what we in our experience as well. 22 00:01:03,608 --> 00:01:04,598 Yeah, absolutely. 23 00:01:04,748 --> 00:01:06,158 I'm very interested in this. 24 00:01:06,163 --> 00:01:10,778 And as, as you mentioned, there was a recent blog post by Paul Ramsey at Crunchy Data. 25 00:01:11,078 --> 00:01:17,688 And I was lucky enough to be able to see a, talk at Postgres London by Thomas Vondra about some of the 26 00:01:18,063 --> 00:01:19,953 Oh, and also you, you was. 27 00:01:20,163 --> 00:01:20,433 Yeah. 28 00:01:20,483 --> 00:01:27,413 Let me repeat the thoughts I expressed last time, I think all conferences should start recording. 29 00:01:27,463 --> 00:01:33,173 In terms of my personal materials , I'm going to only to attend conferences which record. 30 00:01:33,173 --> 00:01:41,393 I think it's very important to present to wider audience because not everyone can travel and, it's just much more 31 00:01:41,393 --> 00:01:49,603 efficient if you present to offline audience and you have good, connection to them and follow up discussions after your talk. 32 00:01:49,813 --> 00:01:58,768 But also if you have recorded material, this is forever, it's published and you can refer to your, previous materials and 33 00:01:58,768 --> 00:02:02,728 you can also see some mistakes you've made and, and fix later. 34 00:02:02,778 --> 00:02:10,483 I saw how other conferences outside the Postgres community did it during many, many years. 35 00:02:10,483 --> 00:02:19,953 And it also, it's also beneficial for conference itself because these like cloud of materials accumulated over years, it attracts 36 00:02:20,103 --> 00:02:23,043 even more attention to the conference and it increases the value. 37 00:02:23,313 --> 00:02:25,683 So I think conferences, which don't record. 38 00:02:26,538 --> 00:02:29,068 They shouldn't, exist anymore at some point. 39 00:02:29,098 --> 00:02:30,708 This is my strong belief. 40 00:02:31,128 --> 00:02:38,188 So, as I've said in San Jose, I, I made announcement that I'm not going to present anymore if conference is not providing recording. 41 00:02:38,398 --> 00:02:41,128 So I'm glad that you saw Thomas Vondra, right? 42 00:02:41,188 --> 00:02:42,328 You, you was there? 43 00:02:42,467 --> 00:02:43,007 Yes. 44 00:02:43,007 --> 00:02:43,637 And it was, 45 00:02:43,738 --> 00:02:46,108 and you saw it, but we have slides. 46 00:02:46,108 --> 00:02:47,548 We don't have video, unfortunately. 47 00:02:47,548 --> 00:02:47,938 Right. 48 00:02:47,957 --> 00:02:48,827 Yes, good point. 49 00:02:48,827 --> 00:02:50,882 He was great and he published his slides. 50 00:02:50,882 --> 00:02:56,102 I'm not actually a hundred percent sure it's the exact slides from Postgres London, but I think he's given this talk a couple of times. 51 00:02:56,102 --> 00:02:57,002 So it's from one of them. 52 00:02:57,121 --> 00:02:59,431 I hope he will give it one more time online. 53 00:02:59,431 --> 00:03:03,601 I already asked to invite him to Postgres TV open talk series. 54 00:03:03,606 --> 00:03:07,356 So I hope we will have recording if he accepts. 55 00:03:07,356 --> 00:03:08,406 It'll be great. 56 00:03:08,655 --> 00:03:09,165 Wonderful. 57 00:03:09,405 --> 00:03:11,870 Anyone listening that will be on Postgres TV, if we get it. 58 00:03:11,921 --> 00:03:12,251 Right. 59 00:03:12,491 --> 00:03:15,521 So we have Postgres FM, Postgres TV, quite easy to remember. 60 00:03:15,521 --> 00:03:15,791 Right. 61 00:03:15,791 --> 00:03:20,376 And, since we discussed it, everyone, please subscribe and, help us to grow. 62 00:03:20,466 --> 00:03:23,766 Uh, what, what can help of course, if you subscribe can help. 63 00:03:23,766 --> 00:03:35,481 And also if you share links to Postgres FM to particular episodes or just to Postgres FM webpage in your social networks and groups where we discuss 64 00:03:35,481 --> 00:03:40,101 Postgres or engineering in general, it would be, very helpful for us to grow. 65 00:03:40,311 --> 00:03:40,971 So please do it. 66 00:03:41,875 --> 00:03:42,205 Brilliant. 67 00:03:42,445 --> 00:03:45,145 Well, so block range indexes. 68 00:03:45,225 --> 00:03:47,325 So we have our default index type. 69 00:03:47,475 --> 00:03:54,795 If I just create an index in, in Postgres, it'll create, a B- tree, which is the default great default, uh, has got a lot of benefits. 70 00:03:54,825 --> 00:03:55,425 It's brilliant. 71 00:03:55,525 --> 00:03:59,025 But we do have other options and one of those is BRIN. 72 00:03:59,725 --> 00:03:59,965 Yeah. 73 00:04:00,355 --> 00:04:04,095 Speaking of B-tree, I think in, in every database system it's default. 74 00:04:04,515 --> 00:04:11,465 And this is my favorite question, but also very tricky question, when you interview some engineer, you feel it's quite good engineer, 75 00:04:11,465 --> 00:04:21,085 but if you like, pull this question out of your set of prepared questions, like what's b-tree and let's discuss the structure and 76 00:04:21,085 --> 00:04:26,215 balancing in many, many cases, interview is over, unfortunately. 77 00:04:26,270 --> 00:04:33,270 So, so I think every engineer should know it, but many, there are many, many engineers who don't know, unfortunately what B-tree is, 78 00:04:33,330 --> 00:04:36,890 but B-tree of course, is a standard defacto for database systems. 79 00:04:37,790 --> 00:04:38,120 Right. 80 00:04:38,260 --> 00:04:47,090 But it's not enough in many cases, it's like not enough in terms of performance, uh, and B-tree can be, can degrade 81 00:04:47,110 --> 00:04:52,390 over time, quite, like a lot, or it can be big one, right? 82 00:04:52,390 --> 00:04:54,370 In terms of like size occupied. 83 00:04:54,370 --> 00:05:03,100 And also like when you talk about size, it's not only disc space occupied, but also, part of buffer pool, the cache state. 84 00:05:03,130 --> 00:05:11,450 So if index is huge, it means, your buffer pool needs to keep more pages, more buffers, in the pool, right. 85 00:05:12,240 --> 00:05:21,235 I, I just wanted to, provide some remarks about B-tree because also like some meta remark, additionally, uh, we have got very good feedback. 86 00:05:21,235 --> 00:05:28,165 Thank you to everyone, for feedback, it's very important for us to hear, what you think about our show and the ideas. 87 00:05:28,705 --> 00:05:35,835 Uh, and we also got some, couple of guys mentioned that we, we like quite basic material, right? 88 00:05:35,865 --> 00:05:43,125 Let's do some more hardcore, but I'm a hundred percent sure that there are many, many people who need basic material. 89 00:05:43,125 --> 00:05:49,470 So I think we need to continue to talk about some basics, but sometimes trying to go deeper. 90 00:05:49,470 --> 00:05:49,920 Of course. 91 00:05:49,920 --> 00:05:50,190 Right. 92 00:05:50,458 --> 00:05:57,328 So that's why I talk about B-tree, because if we jump straight to BRIN, well, B-tree is default. 93 00:05:57,328 --> 00:05:59,908 So it's, it's, it's important to understand how it works. 94 00:06:00,322 --> 00:06:02,602 Well, and BRIN is quite advanced I would say. 95 00:06:02,692 --> 00:06:08,917 I think a lot of people can go a long way using Postgres and there's not a sensible case for using BRIN 96 00:06:08,917 --> 00:06:11,187 or there's no need to know about it for a long time. 97 00:06:11,427 --> 00:06:16,757 And you, mentioned, already a few of the times where B-tree can get cumbersome. 98 00:06:16,757 --> 00:06:20,897 And I think the, the big one here is, size just raw. 99 00:06:20,897 --> 00:06:26,707 You know, if you've got a very, very large table and your indexing a column on it, it can be a very, very large index. 100 00:06:26,998 --> 00:06:28,278 And index bloat. 101 00:06:28,308 --> 00:06:29,328 Yep, absolutely. 102 00:06:29,778 --> 00:06:36,053 And then the other thing that got brought up by Paul Ramsey in his blog post, which I had n't actually considered 103 00:06:36,053 --> 00:06:41,053 before was there can be a difference in write overhead. 104 00:06:41,263 --> 00:06:47,173 So B-tree having a, higher write overhead on average than some other index types. 105 00:06:47,413 --> 00:06:50,623 So that's, that's one other final, downside sometimes. 106 00:06:50,978 --> 00:06:51,368 Yeah. 107 00:06:51,368 --> 00:06:53,998 This famous index write amplification. 108 00:06:54,668 --> 00:06:58,298 One of the reasons Uber went from Postgres to MySQL. 109 00:06:58,318 --> 00:06:58,498 Right? 110 00:06:58,948 --> 00:07:04,268 So each time we update a row, all indexes, should be updated unless it's HOT update. 111 00:07:04,298 --> 00:07:05,558 So it's, a big problem. 112 00:07:05,563 --> 00:07:05,978 Of course. 113 00:07:06,348 --> 00:07:11,368 So, if you have just one index, it's just one update additionally, to the heap update. 114 00:07:11,398 --> 00:07:14,883 But if we have 10 indexes, overhead becomes bigger and bigger. 115 00:07:14,883 --> 00:07:19,713 That's why you need to get rid of unused indexes and redundant indexes right? 116 00:07:19,968 --> 00:07:26,093 Yeah, but the one thing I hadn't considered was that different index types could have massively different overheads to one another. 117 00:07:26,573 --> 00:07:26,993 And that, 118 00:07:27,218 --> 00:07:33,968 Well, well, well, it's, it's very common for example, to have issues, with updating of GIN, there is, there 119 00:07:33,968 --> 00:07:36,488 are special options, like fast update and so on. 120 00:07:36,488 --> 00:07:45,273 So GIN updates are very heavy, expensive, but of B-tree, like it's like medium level of overhead in terms of updates. 121 00:07:45,328 --> 00:07:49,993 But BRIN is definitely like light, light, super low. 122 00:07:51,068 --> 00:07:57,428 Do you think it's fair to say that the biggest advantage of Brin indexes is their size? 123 00:07:57,488 --> 00:08:03,338 So they're, at least in order of magnitude, often two orders of magnitude smaller than a B tree index. 124 00:08:04,298 --> 00:08:04,958 Well, right. 125 00:08:04,958 --> 00:08:12,068 So if, you don't know about B-tree, you should definitely start with Wikipedia as soon as possible if you consider yourself engineer. 126 00:08:12,068 --> 00:08:12,368 Right. 127 00:08:12,488 --> 00:08:15,508 But what is BRIN index? 128 00:08:15,668 --> 00:08:27,963 It's quite simple structure, which, describes, which, um, like in, in the B-tree pages we have links to, uh, tuples 129 00:08:27,983 --> 00:08:31,713 and, but not direct for, for each tuple, but for ranges. 130 00:08:31,733 --> 00:08:41,636 So we describe like this page in heap has, tuples starting from this ID or timestamp or something, starting with this number till this number. 131 00:08:41,636 --> 00:08:43,796 So everything in between is, there. 132 00:08:44,286 --> 00:08:47,366 Of course multiple pages can be referenced in this way. 133 00:08:47,716 --> 00:08:55,356 By default it's 128 pages can be referenced for one range, but it can be adjusted. 134 00:08:55,786 --> 00:09:04,546 So, so in this case, like interesting here is that this index directly dictates you that like you should think 135 00:09:04,546 --> 00:09:08,356 about physical layout because B-tree directly doesn't do it. 136 00:09:08,476 --> 00:09:08,686 Right. 137 00:09:08,686 --> 00:09:20,116 So of course we know that if, for example, you have some value, or range, and B-tree says that these two are located in that heap pages. 138 00:09:20,116 --> 00:09:29,835 And for example, we have a thousand tuples and each one is in separate pages, a thousand pages it's called sparse storage. 139 00:09:30,395 --> 00:09:35,905 You can run cluster command and reorganize your heap. 140 00:09:36,225 --> 00:09:39,825 So the storage will be according to this index. 141 00:09:40,005 --> 00:09:40,275 Right. 142 00:09:40,275 --> 00:09:43,365 And in this case, probably they will all go to a few pages. 143 00:09:43,875 --> 00:09:50,175 So fetching such tuples will be extremely fast compared to these sparse storage. 144 00:09:50,565 --> 00:10:02,460 But BRIN index directly says I'm useful only if your tuples in heap are stored sequentially, according to ID or timestamp. 145 00:10:02,670 --> 00:10:10,390 So in this case, uh, for this particular range, only a few pages will be referenced right. 146 00:10:10,690 --> 00:10:13,870 The way I've heard it described is it's, it's all about correlation. 147 00:10:13,870 --> 00:10:17,080 And if they're exactly in order a hundred percent correlated. 148 00:10:17,770 --> 00:10:18,550 It's optimal. 149 00:10:18,550 --> 00:10:29,340 And, you can get really good performance there because the index can be used to filter out the vast majority of the, of the blocks from being scanned. 150 00:10:29,430 --> 00:10:31,650 And it only has to look at a small number. 151 00:10:32,010 --> 00:10:36,210 But as it gets less correlated, uh, performance degrades. 152 00:10:36,210 --> 00:10:43,650 And if it's, if there are some, uh, exceptions and it makes the, makes the ranges wider than they, than 153 00:10:43,650 --> 00:10:46,190 they ideally should be, it can degrade quite quickly. 154 00:10:46,190 --> 00:10:47,140 And overlapping. 155 00:10:47,160 --> 00:10:48,240 also overlapping. 156 00:10:48,570 --> 00:10:48,870 Right. 157 00:10:49,590 --> 00:10:51,960 So, so like, okay. 158 00:10:52,080 --> 00:11:00,510 Uh, yeah, not overlapping, but, uh, the same range can be, uh, used many times, because more than 128 pages are referenced for this range. 159 00:11:00,510 --> 00:11:07,015 So it's not good, but like how can we check, the physical storage aspects? 160 00:11:07,095 --> 00:11:14,545 There is a hidden column called CTID you cannot create a column called CTID right, because it's a system name it's reserved. 161 00:11:15,075 --> 00:11:17,245 But, what CTID is? 162 00:11:17,245 --> 00:11:18,235 It's in two numbers. 163 00:11:18,235 --> 00:11:22,125 One number is page number and second number is offset inside page. 164 00:11:22,815 --> 00:11:28,595 First number is the most important, and there is a trick how to extract it, for like various, I don't know, like 165 00:11:28,835 --> 00:11:33,575 to, to count distinct number of pages, for particular row. 166 00:11:34,425 --> 00:11:34,845 It's easy. 167 00:11:34,845 --> 00:11:41,815 You can convert it to point and then extract only first, like to point, I mean, X, Y, right. 168 00:11:41,875 --> 00:11:44,460 And then you can take only first argument. 169 00:11:44,460 --> 00:11:46,890 And in this case you will get only page. 170 00:11:47,370 --> 00:11:50,930 This is how you can extract only page number from CTID. 171 00:11:51,510 --> 00:11:55,700 So you can check your data always. 172 00:11:56,090 --> 00:12:04,850 And, check what CTIDs, or just page numbers with this trick you can check and you can see exactly if, if you can see this correlation, right? 173 00:12:04,855 --> 00:12:15,200 So if you have sequential ID used or timestamp, which is filled by some, uh, like now or better in this case, clock timestamp, 174 00:12:15,220 --> 00:12:18,160 because now is generated only in the beginning of transaction. 175 00:12:18,490 --> 00:12:25,810 So if you insert, you have some batch insert thousand rows, all of them will have the same now value, but clock timestamp 176 00:12:25,810 --> 00:12:29,140 will generate timestamp for each row inserted, right. 177 00:12:29,470 --> 00:12:31,660 And you will have difference in values, right? 178 00:12:32,080 --> 00:12:33,490 And in this case, you can. 179 00:12:34,030 --> 00:12:41,440 Check select CTID convert to point and get first argument and then ID or created at. 180 00:12:41,440 --> 00:12:51,015 And you can see if there is correlation or you, I think you can even apply some, functions to prove that correlation correlation is strong. 181 00:12:51,105 --> 00:12:51,405 Right? 182 00:12:51,562 --> 00:12:53,632 Maybe it's a good exercise. 183 00:12:53,706 --> 00:13:01,911 But the cases I hear about this are like people actually using these in the real world tend to be cases where you're pretty sure it's 184 00:13:01,916 --> 00:13:10,161 correlated already because you've been inserting timestamped data in order, you know, maybe it's a sensor reporting data and you. 185 00:13:11,061 --> 00:13:11,991 You never update it. 186 00:13:11,991 --> 00:13:13,041 You never delete it. 187 00:13:13,071 --> 00:13:15,981 It's all in order and you can 188 00:13:16,241 --> 00:13:17,587 delete is De delete is okay. 189 00:13:17,647 --> 00:13:18,757 Only update matters. 190 00:13:18,852 --> 00:13:19,362 Good point. 191 00:13:19,362 --> 00:13:19,782 Good point. 192 00:13:19,932 --> 00:13:20,262 Yep. 193 00:13:21,463 --> 00:13:29,257 so you can check for sure, but equally that's the case where it's most likely to be relevant or at least until the latest version. 194 00:13:29,467 --> 00:13:34,572 I think those cases were pretty much the only good use case for BRIN when you had 195 00:13:35,422 --> 00:13:36,232 exactly. 196 00:13:36,779 --> 00:13:38,249 Yeah, let me describe once more. 197 00:13:38,249 --> 00:13:46,489 I'm trying to like, for, as I've said, some basics to describe some basics, uh, so once you've learned what CTID is, I recommend 198 00:13:46,489 --> 00:13:54,379 you to create some table with, uh, surrogate, primary key like sequentially, some generated number or some like sequence. 199 00:13:55,029 --> 00:14:02,669 and then like for example, we have a row where ID is one and we, we see that it's it's inside page zero. 200 00:14:02,699 --> 00:14:03,659 We've said zero. 201 00:14:03,689 --> 00:14:04,019 Okay. 202 00:14:04,619 --> 00:14:05,399 But then. 203 00:14:06,234 --> 00:14:09,954 I recommend you to execute, update this table. 204 00:14:09,954 --> 00:14:14,594 Set ID equals ID, where ID equals one and see what happens with CTID. 205 00:14:14,609 --> 00:14:23,934 This is very interesting because it may be unexpected for you because, uh, you will see that CTID value changes sometimes page is the same. 206 00:14:23,934 --> 00:14:33,474 If there is, there is space inside the page, but you see how tuple, which is a row version, physical row version is generated new tuple generated. 207 00:14:33,474 --> 00:14:39,624 Always, even if you logically didn't do update like ID equals ID means we don't do anything right. 208 00:14:40,764 --> 00:14:43,434 but you see how tuple is generated. 209 00:14:43,464 --> 00:14:47,364 Uh, that's why updates can shuffle your data, right? 210 00:14:47,444 --> 00:14:52,614 You, you can have, uh, correlation can be worse over time. 211 00:14:53,154 --> 00:14:53,484 Yes. 212 00:14:53,534 --> 00:15:00,399 Let's use an example where if I have some really old data and maybe I found out the sensor was incorrect or had a bug in it, and some of 213 00:15:00,399 --> 00:15:09,459 the data needs to be updated if I update some of that old data what Postgres will really do is insert new rows at the bottom of the heap. 214 00:15:09,879 --> 00:15:10,669 And then mark 215 00:15:10,979 --> 00:15:14,506 Or in some pages where there is a space. 216 00:15:14,894 --> 00:15:15,314 Yes. 217 00:15:15,314 --> 00:15:15,884 Good point. 218 00:15:15,914 --> 00:15:16,154 Yeah. 219 00:15:16,154 --> 00:15:16,394 Good 220 00:15:16,526 --> 00:15:16,816 Yeah. 221 00:15:16,886 --> 00:15:17,176 Good 222 00:15:17,204 --> 00:15:18,704 but not in the same. 223 00:15:18,764 --> 00:15:19,304 Yes. 224 00:15:19,724 --> 00:15:22,524 But then that reduces the correlation of that table. 225 00:15:22,561 --> 00:15:23,071 Exactly. 226 00:15:23,578 --> 00:15:24,188 Brilliant. 227 00:15:24,935 --> 00:15:28,405 Or, or like we have some import of old data. 228 00:15:28,405 --> 00:15:29,635 We are missing let's. 229 00:15:30,310 --> 00:15:33,040 Not update, but insert can be problem as well. 230 00:15:33,160 --> 00:15:38,260 If we insert all data like postponed, insert, right? 231 00:15:38,470 --> 00:15:39,580 Delete is not a problem. 232 00:15:39,820 --> 00:15:43,960 I like, I, I don't foresee problem with gel delete, but postponed, inserts and updates. 233 00:15:43,960 --> 00:15:52,630 And also, you know what, probably a problem, uh, repacking, if you run pg_repack, the pack allows you to achieve the same 234 00:15:52,635 --> 00:15:57,385 effect as cluster but without downtime, not blocking for long. 235 00:15:57,865 --> 00:15:58,165 Right? 236 00:15:58,165 --> 00:16:09,155 So if someone, some DBAs, for example, didn't notice that there is a BRIN index, which requires this correlation, with physical storage, and decided 237 00:16:09,155 --> 00:16:21,320 to perform repacking using pg_repack and, use clustering according to some, another column or index, you will get very different physical storage 238 00:16:21,980 --> 00:16:26,600 and correlation will be not good at all in terms for your BRIN index. 239 00:16:26,763 --> 00:16:27,483 Interesting. 240 00:16:27,483 --> 00:16:30,183 I thought, I thought pg_repack would help. 241 00:16:30,323 --> 00:16:31,653 Have you heard of pg_squeeze? 242 00:16:31,678 --> 00:16:34,405 That's one I've I'm aware of that's an alternative to pg_repack. 243 00:16:34,475 --> 00:16:38,650 pg_squeeze I've read about it, checked it, but I mean, I didn't use it yet. 244 00:16:38,680 --> 00:16:46,420 It's, it's interesting idea to use logical decoding, instead of this pg_repack approach with like substitution of table. 245 00:16:46,640 --> 00:16:49,625 It's, it's really interesting idea with delta table, right? 246 00:16:49,630 --> 00:16:58,935 So pg_repack writes all changes in some delta table and then sometimes it's a, it's a challenge, to apply. 247 00:16:59,020 --> 00:17:05,420 It's because delta changes from this delta table should be applied , need to be applied in a single transaction. 248 00:17:05,420 --> 00:17:09,530 So if a lot of changes are accumulated can be and can be a problem. 249 00:17:09,800 --> 00:17:19,130 But, but if you, I mean, if you use repacking with cluster option, uh, using different, for example, you may have, 250 00:17:19,190 --> 00:17:24,260 uh, I don't know, like, like some name, column, right? 251 00:17:24,470 --> 00:17:25,190 Alphabetical. 252 00:17:25,370 --> 00:17:27,840 And you want to reorganize your heap. 253 00:17:28,885 --> 00:17:38,735 You have, uh, pages, uh, you need to present the data with pagination, order by name and you think this is the most useful use case for you. 254 00:17:38,735 --> 00:17:41,025 So you decided to reorganize heap. 255 00:17:41,455 --> 00:17:45,565 So the data in, in heap is ordered according name. 256 00:17:45,655 --> 00:17:49,315 So there is correlation with name not with ID. 257 00:17:50,215 --> 00:17:55,225 Created at timestamp and your BRIN in this case will, will, perform not, not good. 258 00:17:55,328 --> 00:17:56,588 Unless it's a BRIN on name. 259 00:17:57,848 --> 00:17:58,198 Right. 260 00:17:58,468 --> 00:18:00,888 But I've actually thought of a problem with delete as well. 261 00:18:01,295 --> 00:18:07,415 Once you've de once you've deleted those rows in the, let's say in the middle of your heap and it's vacuumed 262 00:18:07,685 --> 00:18:10,625 later, new inserts are now gonna go in the middle. 263 00:18:10,737 --> 00:18:10,937 Yeah. 264 00:18:10,937 --> 00:18:11,207 So 265 00:18:11,207 --> 00:18:13,240 now we've got a problem again, but, anyway, 266 00:18:13,347 --> 00:18:13,587 point. 267 00:18:13,617 --> 00:18:14,107 Good point. 268 00:18:14,260 --> 00:18:21,310 This was a, this is interesting, cause I think it slightly takes us onto the improvements that Thomas was talking about in 269 00:18:21,357 --> 00:18:21,537 Yeah, 270 00:18:21,730 --> 00:18:22,150 14. 271 00:18:23,067 --> 00:18:24,187 because we discussed this. 272 00:18:24,837 --> 00:18:25,107 Yeah. 273 00:18:25,347 --> 00:18:25,947 So. 274 00:18:26,487 --> 00:18:31,062 So, just to make some conclusion before we discuss improvements in Postgres 14. 275 00:18:31,122 --> 00:18:39,447 So it, it means that before Postgres 14 BRIN can be used only, if you definitely have append only pattern for your 276 00:18:39,452 --> 00:18:48,002 table, log like table, you log some events or some data from some like some telemetry data from somewhere and so on. 277 00:18:48,932 --> 00:18:50,882 Right in this case, BRIN can be. 278 00:18:51,795 --> 00:18:55,485 Or it degrades quickly and you need to reindex regularly. 279 00:18:55,515 --> 00:19:01,015 Like I, I guess there are some use cases if, um, if you do update data and then reindex. 280 00:19:01,380 --> 00:19:04,050 You, I guess you have some benefits still. 281 00:19:04,440 --> 00:19:08,100 Um, but it degrades quickly and maybe there isn't the benefits. 282 00:19:08,160 --> 00:19:08,820 Maybe you're better 283 00:19:08,942 --> 00:19:12,122 hold on a re-index can reindex help? 284 00:19:12,127 --> 00:19:14,372 Like clustering can help. 285 00:19:14,642 --> 00:19:17,642 So you need to organize hip, but re like yeah. 286 00:19:19,010 --> 00:19:22,650 Maybe repacking and then re-indexing 287 00:19:23,560 --> 00:19:25,420 maybe maybe, this, this is interesting. 288 00:19:25,420 --> 00:19:28,360 Do we need re-indexing, but yeah, but it's, it's slight anyway. 289 00:19:28,883 --> 00:19:29,483 Yes. 290 00:19:29,993 --> 00:19:30,443 Um, 291 00:19:30,460 --> 00:19:31,930 it's very light to build 292 00:19:31,943 --> 00:19:36,923 popular like that use case is not, is, you know, lots of people have logging tables. 293 00:19:36,928 --> 00:19:38,273 Lots of people do have this 294 00:19:38,373 --> 00:19:48,953 do you yeah, but, but, the problem is I always, like, I, I tried at least three times over a few last years since BRIN 295 00:19:49,073 --> 00:19:54,453 popped up, like was, was created, never decided to go with BRIN. 296 00:19:54,503 --> 00:19:54,833 Never 297 00:19:55,371 --> 00:19:56,691 Interesting. 298 00:19:57,113 --> 00:19:59,243 I, I didn't find it useful, like, okay. 299 00:19:59,243 --> 00:20:03,533 We, the size of it is quite small, but. 300 00:20:04,478 --> 00:20:14,228 It always on large volumes of data, it always performed worse than B-tree for me, much worse, maybe because I had like these, these materials, 301 00:20:14,228 --> 00:20:17,558 both materials were mentioned and we will provide links in description. 302 00:20:18,258 --> 00:20:21,558 They both mentioned that for like point, searches. 303 00:20:21,558 --> 00:20:25,588 Like when you need only one row or a couple of rows, BRIN is not attractive. 304 00:20:26,308 --> 00:20:36,598 Maybe I had closer to this or like I needed only 20 rows for pagination and so on, but when you need to find many, many rows, like thousands of rows 305 00:20:37,748 --> 00:20:42,728 BRIN can outperform B-tree, I just never, I, I always, when I need to decide. 306 00:20:43,513 --> 00:20:44,533 What I should use. 307 00:20:44,533 --> 00:20:45,733 I do experiments. 308 00:20:45,793 --> 00:20:52,843 I'm like huge fan of, I, I I'm building company on top of idea of experimenting, experimenting with always, 309 00:20:52,843 --> 00:20:55,483 always, always for learning, for making decision. 310 00:20:56,093 --> 00:21:03,688 It's the best case if you can experiment with production data or like similar to production without PII, without personal 311 00:21:03,688 --> 00:21:17,028 data, but I never decided to use BRIN because I saw them less performant, to B-tree even for update only only inserts. 312 00:21:17,131 --> 00:21:17,821 I'm the same. 313 00:21:17,821 --> 00:21:23,011 I've only ever seen, B-tree outperform BRIN in terms of raw query performance. 314 00:21:23,031 --> 00:21:30,821 I think there's a good example in the, in the Crunchy Data blog post, where in lab conditions, BRIN can outperform B-tree, 315 00:21:30,908 --> 00:21:31,398 perform, 316 00:21:32,021 --> 00:21:32,531 in the real 317 00:21:32,898 --> 00:21:39,248 uh, uh, I have, uh, Like let me to have some disclaimer. 318 00:21:39,638 --> 00:21:45,818 Uh, last time I was like a bad cop guy who criticized a lot of various stuff I'm going to continue. 319 00:21:45,848 --> 00:21:56,598 So, but like, like I thi I see value in criticism, but, I'm going to be like, Polite, maybe sometimes not very polite, but I, 320 00:21:56,598 --> 00:22:01,368 because I, often have, um, some, uh, opinion, quite strong opinion. 321 00:22:01,428 --> 00:22:01,758 Right. 322 00:22:01,788 --> 00:22:04,428 But I hope, uh, nobody will be offended. 323 00:22:04,428 --> 00:22:07,608 And, uh, just for improving things, not for. 324 00:22:08,473 --> 00:22:09,553 Uh, damage. 325 00:22:09,643 --> 00:22:09,943 Right. 326 00:22:10,333 --> 00:22:19,423 And I also can be sometimes very wrong and I, I, I quickly admit it if I see evidence that I'm wrong, but in this case, I want to criticize 327 00:22:19,428 --> 00:22:22,993 both materials from both from, from Paul Ramsey and Thomas Vonda. 328 00:22:24,053 --> 00:22:31,263 I cannot understand how we can talk about performance and, physical layout and so on and provide plans without buffers. 329 00:22:31,563 --> 00:22:32,973 It's huge mistake. 330 00:22:33,773 --> 00:22:42,033 Simply huge mistake because we discuss how BRIN, uh, can be more, uh, better in terms of performance than B-tree. 331 00:22:42,083 --> 00:22:49,913 And talk about some timing, which is have a lot of fluctuations. 332 00:22:49,943 --> 00:22:50,303 Right. 333 00:22:51,143 --> 00:22:58,723 And that's not reliable, at least, at least you need to run it multiple times and take some average if you talk about timing. 334 00:22:58,723 --> 00:23:07,903 So, and, and also Paul Ramsey's blog post also makes some conclusions based only just from a single point of data, 335 00:23:07,903 --> 00:23:11,893 for example, like 10 rows 100 rows 1000 rows, 10,000 rows. 336 00:23:11,953 --> 00:23:12,343 Okay. 337 00:23:12,343 --> 00:23:13,483 We see BRIN is better. 338 00:23:13,903 --> 00:23:23,803 What, like, I'm not convinced I'm not convinced because I saw for huge and also like million rows, seriously million rows is, is nothing today. 339 00:23:24,553 --> 00:23:26,263 Test at least of billion rows. 340 00:23:26,263 --> 00:23:26,563 Right. 341 00:23:26,953 --> 00:23:36,763 So, so sorry for maybe I'm offensive, but I just it's so like, I just want everyone to, to, to have better materials. 342 00:23:36,763 --> 00:23:44,263 It's great to discuss performance, but don't do plans of explain, analyze, do plans with explain (analyze, buffers). 343 00:23:44,293 --> 00:23:45,583 We will see IO. 344 00:23:45,613 --> 00:23:46,873 IO is most important. 345 00:23:46,873 --> 00:23:51,613 All indexes are needed to reduce number of IO operations. 346 00:23:52,693 --> 00:24:02,198 Index is all about reducing IO, any index we want instead of making like a lot of buffer hits and reads we want to have a 347 00:24:02,198 --> 00:24:06,488 few buffer hits and hits to fetch one or, or thousand rows. 348 00:24:07,298 --> 00:24:14,408 We don't want to have, uh, million, uh, hits and res when we need only thousand of rows. 349 00:24:15,038 --> 00:24:19,688 But when you talk timing, I don't understand where this timing comes from. 350 00:24:19,898 --> 00:24:27,638 When I see buffers, I understand, oh, this timing goes from a huge, uh, reads and buffer res and hits numbers. 351 00:24:27,876 --> 00:24:29,286 yeah, really good point. 352 00:24:29,436 --> 00:24:36,861 And I think actually there's a couple more dis, so the reason I was always, um, always used to think until the, until the blog 353 00:24:36,861 --> 00:24:45,111 post and until a couple of things that Thomas said, I always thought BRIN couldn't outperform B-tree because it only has 354 00:24:45,111 --> 00:24:50,061 the ability to do bitmap heap scans or bitmap scans in general. 355 00:24:50,511 --> 00:24:53,841 And so a B-tree can also do a bitmap scan. 356 00:24:53,841 --> 00:25:00,771 So the only slight advantage is that you have to build the bitmap if you're using a B-tree. 357 00:25:00,861 --> 00:25:05,421 So there's slight overhead there for the B tree, but it's also efficient. 358 00:25:05,421 --> 00:25:10,431 So it's looking at exactly the blocks it needs, whereas the bit the, um, 359 00:25:11,303 --> 00:25:16,583 When you say you need to build it, you mean, uh, you as executor, which will do it right? 360 00:25:16,731 --> 00:25:17,061 sorry. 361 00:25:17,061 --> 00:25:18,591 Yes, not the user. 362 00:25:18,591 --> 00:25:20,361 no, but they, I was thinking. 363 00:25:20,796 --> 00:25:29,476 The, the executor has to for the B-tree index, but it doesn't have do for the BRIN index, but with a BRIN index, I think you'd 364 00:25:29,476 --> 00:25:31,966 always get false positives back that you have to filter out. 365 00:25:31,966 --> 00:25:36,996 Like you're always gonna get some rows on those blocks that you're gonna then have to get rid of. 366 00:25:37,001 --> 00:25:42,716 So I didn't understand how it could be more efficient but the, the main advantage I always thought was the size. 367 00:25:42,716 --> 00:25:49,616 So instead of having a multi gigabyte index that also then takes up multiple gigabytes in the, in the cahce and all those things. 368 00:25:49,796 --> 00:25:55,376 You could have a, an index that's normally in the kilobytes, or even for very large tables in the megabytes. 369 00:25:55,656 --> 00:25:59,376 So that I always saw that as the main advantage rather than performance. 370 00:25:59,756 --> 00:26:08,866 You know, if, for example, if we just created the table, filled it with data and forgot to run vacuum, and I see Crunchy blog post blocks it, 371 00:26:09,526 --> 00:26:13,676 in this case, you will have the plan with, btimap index scan, right? 372 00:26:14,711 --> 00:26:25,441 and in this case, I, I can imagine that BRIN will be efficient if you have huge table and you need to find and fetch a lot of rows should be there. 373 00:26:25,471 --> 00:26:33,451 But, but like, I would definitely look first of all, on, on like type of operation, like, bitmap index scan. 374 00:26:33,511 --> 00:26:37,261 And also I will, I would look at buffer hits 375 00:26:37,379 --> 00:26:38,039 just remembered. 376 00:26:38,249 --> 00:26:39,299 Yeah, I agree. 377 00:26:39,359 --> 00:26:40,229 One last thing. 378 00:26:40,229 --> 00:26:48,839 That's a bit unfair with the, Crunchy Data blog post, and I know it makes it a slightly fairer comparison, but it's unfair in the real world is that 379 00:26:48,929 --> 00:26:52,859 they also disabled index only scans because BRIN doesn't support them. 380 00:26:53,009 --> 00:26:58,439 So make it a more apples to apples comparison, that's disabled, but in the real world, you might sometimes 381 00:26:58,439 --> 00:27:01,139 get an index-only scan, especially for data that 382 00:27:01,246 --> 00:27:01,456 Yeah. 383 00:27:02,116 --> 00:27:06,706 Michael, Michael, Michael, you, you, you are supposed to be a good cop here. 384 00:27:08,249 --> 00:27:09,419 I didn't agree to this. 385 00:27:09,436 --> 00:27:11,456 Why, why you, okay. 386 00:27:11,526 --> 00:27:11,816 Okay. 387 00:27:12,299 --> 00:27:13,979 Um, yes, but yeah. 388 00:27:14,069 --> 00:27:16,289 Um, Those are all really good points. 389 00:27:16,289 --> 00:27:18,359 I'm really happy that we've brought those up. 390 00:27:18,699 --> 00:27:23,289 I actually do think they're good, uh, content, and I'm glad that they spark in a discussion here. 391 00:27:24,039 --> 00:27:31,479 The other thing that if we're on the more advanced side, um, I do think Brin has improved a lot in the last version. 392 00:27:31,479 --> 00:27:32,289 I didn't know that. 393 00:27:32,714 --> 00:27:37,784 Uh, until, well, I wasn't aware of how much it had until Thomas's talk. 394 00:27:37,994 --> 00:27:44,864 The one thing I really wanted to bring people's attention to is a new operator class, which I'm aware is slightly advanced, 395 00:27:44,869 --> 00:27:52,004 but, um, by default bring index is still behaved pretty much exactly as they did in Postgres 13 and 12, I believe. 396 00:27:52,474 --> 00:27:57,179 But if you change a setting while you're creating the index. 397 00:27:57,179 --> 00:28:04,139 If you create it slightly differently using a new well, there's a couple of different new, uh, operator classes, but the one I'm particularly excited 398 00:28:04,139 --> 00:28:15,599 about is minmax-multi and the, my understanding of that, and it, this might be flawed is that instead of only maintaining a single minimum and maximum 399 00:28:15,689 --> 00:28:20,874 for each block range, It can instead maintain multiple minimum maximums. 400 00:28:21,204 --> 00:28:29,124 Now the, the big advantage of that, I, I, well, so two, two big advantages are, it can support different types of correlation. 401 00:28:29,364 --> 00:28:39,104 So if there are, um, If your data's, uh, oddly maybe not the time stamp example, but may well, actually time stamp example is great. 402 00:28:39,134 --> 00:28:48,614 If we, if we inserted some old data, we would now be able to have two min maxes or probably not two, probably lots more than that, but we 403 00:28:48,614 --> 00:28:54,404 could have the new data and the old data and a big gap in the middle where Postgres knows it doesn't have any data for that big gap. 404 00:28:55,154 --> 00:29:03,949 So at worst they'd degrade much less badly, but I think it's a huge, huge improvement that could support 405 00:29:03,949 --> 00:29:06,079 a lot of different types of correlation as well. 406 00:29:06,409 --> 00:29:14,389 And I'm interested why, well, I, I think it could be so useful that it should be the new default for Brin, but I do understand that defaults 407 00:29:14,389 --> 00:29:17,779 are difficult to change and you might not want to affect existing users. 408 00:29:17,829 --> 00:29:20,009 To me it sounds like, uh, game changer. 409 00:29:21,094 --> 00:29:24,334 And like, I, I'm looking forward to testing it once again. 410 00:29:24,394 --> 00:29:31,419 Unfortunately, I still don't have any real big production with Postgres 14, but once I have it, uh, next time, like 411 00:29:31,659 --> 00:29:36,429 for me, it's a reset of my, opinion about BRIN indexes. 412 00:29:36,429 --> 00:29:41,889 So, because as I've said in the past, they like, I made decisions not, not go. 413 00:29:41,889 --> 00:29:51,189 And I like next time I would probably not spend any time, uh, not waste this time, double checking, but now I definitely will double 414 00:29:51,189 --> 00:29:57,519 check, uh, for, for the cases when this correlation is not perfect. 415 00:29:57,609 --> 00:30:07,429 And we have some, some, not in intensive, but, like occasional updates or delete deletes or postponed inserts as we discussed. 416 00:30:07,849 --> 00:30:08,719 It's sounds interesting. 417 00:30:08,719 --> 00:30:17,989 And I also see like, like to be fair, uh, Paul Ramsey's article describes doesn't describe this improvements, but it, it talks 418 00:30:17,994 --> 00:30:23,874 about, uh, pages per range option that was available before already. 419 00:30:23,874 --> 00:30:31,524 And you can play, try to play with this parameter and see how performance in your particular case is affected negatively or 420 00:30:31,529 --> 00:30:41,954 positively, and also mentions, pgstattuple extension, to check like physical layout of pages, and see what's happening under the hood. 421 00:30:42,234 --> 00:30:43,564 This is very, very good. 422 00:30:43,624 --> 00:30:51,094 I, I mean to remind about these capabilities, this is helpful if you, uh, run your own experiments. 423 00:30:51,454 --> 00:30:52,834 So good, good thing. 424 00:30:53,164 --> 00:31:01,894 But Thomas Vondra discussing improvements also show some good examples and, uh, I've noticed that these Uh, operator, classes, 425 00:31:01,954 --> 00:31:05,274 uh, it looks like they are available for various data types, right. 426 00:31:06,474 --> 00:31:15,234 And, UUID is there, this is interesting because UUID is usually considered as like randomly dis physical distribution is awful, right. 427 00:31:15,744 --> 00:31:18,234 Is and BRIN for UUID is not good. 428 00:31:19,434 --> 00:31:22,434 because you have, like, it's not order. 429 00:31:22,662 --> 00:31:26,972 Some, I think there are some UUID versions that are yeah. 430 00:31:27,212 --> 00:31:27,542 Okay. 431 00:31:27,752 --> 00:31:29,642 But I'm wondering if that's why they've been included. 432 00:31:30,084 --> 00:31:31,134 Actually we use it. 433 00:31:31,134 --> 00:31:34,284 I, I now remember we use some, some location in our tool. 434 00:31:34,404 --> 00:31:37,464 We use some almost, uh, orders. 435 00:31:37,469 --> 00:31:37,734 Right. 436 00:31:38,124 --> 00:31:43,014 But, uh, many versions are not like U U ID V V three. 437 00:31:43,014 --> 00:31:43,434 Before. 438 00:31:43,464 --> 00:31:44,754 I don't remember these things. 439 00:31:45,264 --> 00:31:47,514 They don't look ordered at all. 440 00:31:48,174 --> 00:31:50,244 And, uh, it is interesting to check. 441 00:31:51,864 --> 00:31:58,194 New improved brain index can perform on this, this data type. 442 00:31:58,824 --> 00:32:09,454 So not only, so, I mean, not only it's should be interesting for, for cases which not fully update, only pattern, but also for these kind of data types. 443 00:32:09,497 --> 00:32:16,667 Yeah in person, actually, Thomas made a really good point about this is actually a really good area for new 444 00:32:16,672 --> 00:32:20,267 people that want to contribute to Postgres to explore. 445 00:32:20,297 --> 00:32:26,977 He has got a few ideas of improving these further and indexing in general is quite An isolated part of the code base. 446 00:32:27,157 --> 00:32:34,927 You don't have to understand everything about Postgres to be able to improve things and BRIN indexes, especially they they're isolated. 447 00:32:34,927 --> 00:32:37,987 They're not, uh, the default, so they're not as contentious. 448 00:32:38,047 --> 00:32:43,687 So I think there's a few, um, few good reasons why this would be a good area to get involved in. 449 00:32:43,867 --> 00:32:49,997 And, um, I think Thomas mentioned being willing to help people out if they do want to want to get 450 00:32:49,997 --> 00:32:51,047 started on that kind of thing. 451 00:32:51,107 --> 00:32:51,587 So that would be. 452 00:32:51,939 --> 00:32:53,919 good first issue, right? 453 00:32:54,272 --> 00:32:54,422 right. 454 00:32:54,422 --> 00:32:55,112 The label 455 00:32:56,529 --> 00:33:01,959 if, Postgres used GitHub or GitLab, it would be this label would be there 456 00:33:02,019 --> 00:33:03,639 in this issue, but no, 457 00:33:03,902 --> 00:33:05,672 definitely a topic for another day. 458 00:33:06,369 --> 00:33:07,109 For another day. 459 00:33:07,114 --> 00:33:07,629 Yes. 460 00:33:07,629 --> 00:33:08,169 Oh yeah. 461 00:33:08,199 --> 00:33:08,379 Yeah. 462 00:33:08,379 --> 00:33:10,179 We have several topics like that. 463 00:33:10,929 --> 00:33:11,229 Yeah. 464 00:33:11,229 --> 00:33:12,159 Good, good. 465 00:33:12,249 --> 00:33:21,354 Uh, so, so I, I find these two materials useful, for reminding that you can use this in your experiments or that, but as I've said, I 466 00:33:21,354 --> 00:33:25,184 think everyone should experiment with their own data and, queries. 467 00:33:26,074 --> 00:33:36,454 If you need to make decision don't trust, blog post blindly, experiment with your data and your queries, think about if, even if you don't have data, you 468 00:33:36,454 --> 00:33:42,724 can generate some, like, as close as you think about future and also queries. 469 00:33:42,724 --> 00:33:44,584 And then you can start experimenting. 470 00:33:45,057 --> 00:33:51,247 my, my big piece, there is always to make sure you have the, roughly the right number of rows. 471 00:33:51,307 --> 00:33:58,597 Like everything else matters a bit, but then the, the raw number of rows in the right order of magnitude makes a big, big difference 472 00:33:58,597 --> 00:34:01,027 to which query plans you're gonna see and to overall performance. 473 00:34:01,027 --> 00:34:06,397 So if you do nothing else, please at least insert an appropriate number of rows for testing. 474 00:34:07,229 --> 00:34:15,069 and, I need to add here, uh, on two sides, number of rows on two sides, first number, what number of rows stored in 475 00:34:15,069 --> 00:34:18,329 table, and second number of rows you need for your query. 476 00:34:18,329 --> 00:34:23,909 Sometimes there is no limit in query and then your data is growing. 477 00:34:23,909 --> 00:34:26,159 And this is like, this is a big mistake. 478 00:34:26,159 --> 00:34:29,249 Many people do often do so not limit. 479 00:34:30,164 --> 00:34:30,914 The results set. 480 00:34:32,384 --> 00:34:35,774 And so you need to think how many rows you, your users will need. 481 00:34:35,774 --> 00:34:43,514 Uh, they, they won't need probably million rows if you present this results on some page on mobile or web app, right? 482 00:34:43,694 --> 00:34:46,214 So you need to think about limit and pagination and so 483 00:34:47,362 --> 00:34:48,022 Absolutely. 484 00:34:48,862 --> 00:34:49,462 I think we're done. 485 00:34:50,564 --> 00:34:50,834 Yeah. 486 00:34:50,834 --> 00:34:51,254 Good. 487 00:34:51,532 --> 00:34:53,392 Nothing left in this, in this, topic. 488 00:34:53,442 --> 00:34:58,842 At least, at least in our heads, maybe some people have some, uh, additional thoughts. 489 00:34:58,872 --> 00:35:06,327 Uh, I would love to, to, to see, in comments or in Twitter probably right. 490 00:35:06,410 --> 00:35:11,480 and well, I think we probably could talk about it for a bit more like there's the bloom, like the new, uh, 491 00:35:11,480 --> 00:35:14,000 bloom operating operator class seemed really interesting. 492 00:35:14,005 --> 00:35:16,820 And the, the Minax thing is also configurable. 493 00:35:17,037 --> 00:35:18,177 oh yeah, I 494 00:35:18,185 --> 00:35:19,715 I'm also conscious of time. 495 00:35:20,075 --> 00:35:26,685 And I think we should probably, I think that probably is verging a little bit advance, but there's some really cool things happening in BRIN. 496 00:35:26,705 --> 00:35:32,165 If you haven't considered them for a while, please do, uh, upgrade if you can, to Postgres 14. 497 00:35:32,582 --> 00:35:34,175 to post .What else? 498 00:35:34,225 --> 00:35:34,725 I think, 499 00:35:35,145 --> 00:35:35,945 15 already 500 00:35:35,975 --> 00:35:36,305 Right. 501 00:35:36,395 --> 00:35:38,345 If you're brave, um, 502 00:35:38,445 --> 00:35:41,145 for for testing you not don't need to be brave. 503 00:35:41,145 --> 00:35:44,655 You it's not production testing can, can happen elsewhere. 504 00:35:44,685 --> 00:35:44,925 Right? 505 00:35:44,925 --> 00:35:51,983 So i, I'm not saying upgrade your production to, to 15 beta two it's it's probably 506 00:35:52,231 --> 00:35:52,531 yeah. 507 00:35:52,741 --> 00:35:54,591 Brave is not quite the right word, is it? 508 00:35:55,041 --> 00:35:55,461 Awesome. 509 00:35:55,521 --> 00:35:57,433 Well, thank you everybody for joining us. 510 00:35:57,483 --> 00:36:03,883 And yeah, send us your feedback, let us know what you'd like discussed and yeah, thank you Nikolay, hope you have a good week. 511 00:36:03,923 --> 00:36:04,783 Thank you, Michael. 512 00:36:04,873 --> 00:36:06,260 See you next next week. 513 00:36:06,322 --> 00:36:06,952 See you next week. 514 00:36:06,952 --> 00:36:07,192 Bye.