Postgres FM - GSoC B-Tree Merge

Episode Date: September 25, 2026

Nik and Michael are joined by Salma El-Sayed and Kirk Wolak to discuss their in-progress and very ambitious Google Summer of Code project around adding Btree Merge support to Postgres. Here are some links to things they mentioned:  Salma El-Sayed https://postgres.fm/people/salma-el-sayedKirk Wolak https://postgres.fm/people/kirk-wolakGoogle Summer of Code https://summerofcode.withgoogle.comPostgreSQL GSoC 2026 project ideas https://wiki.postgresql.org/wiki/GSoC_2026CMU Intro to Database Systems https://www.youtube.com/playlist?list=PLSE8ODhjZXjYMAgsGH-GtY5rJYZ6zjsd5Kirk, NIK, and Andrey’s Hacking Postgres sessions on YouTube https://www.youtube.com/playlist?list=PLH8y1BNPAKjKDdJA7sDmFWUkbbYux3TRzB-tree Index Bloat Reduction - Approach & Questions (Hackers thread, with patches) https://www.postgresql.org/message-id/flat/CANBEAPFq3YAOydjUS3xwcUG9L6e3WE5Z4nGPk_Q3RsjSFWTJNA%40mail.gmail.comB-tree merge visualizer https://kirkw.github.io/explainers/btree-merge-explainer.html~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith credit to:Jessie Draws for the elephant artwork

Hello and welcome to Postgres FM. A weekly show about all things Postgres Coral. I am Michael founder of PG Mustard, and I am joined by two special guests. Firstly, Salma El-Sahed recently graduated from the Manzura University in a computer and control engineering degree and Google. And Google Summer of Code participant working on BTU merge for Postgres. Welcome, Salma. Hi, welcome, Rachel. Thank you so much.

Yeah, great to have you. And also Kirk Warlock. who is a software architect at KiroSoft, Google Summer of Code Mentor, and a co-host with Nick on the YouTube Hacking Postgres series. Hi, Kirk. Nice to have you too. Michael, it's good to finally be able to be in one of these with you. Thank you. Yeah, I've watched many of your sessions as well, so it feels like a co-lab maybe.

Kind of. I wondered actually if we could start with you, Kirk. I wonder if you could give us a little bit of background on being a Google Summer of Code mentor. From your perspective, how does that work? For people that aren't familiar with it, what does it mean? Sure. In fact, I just did a lightning round as a mentor because of how we integrated AI, because they're really curious about moving forward.

So first off, Google Summer of Code is an initiative to help bring new people into the open source world. And the ultimate goal is to create new contributors. And I'm taking that completely to heart. So my goal for Salma is to make sure she not only does something big, but we also make it so that she contributes in the future, so much so that we're arranging for other companies to support her in these efforts so that long term, we absolutely have a contributor. My position, it's my first time mentoring, and I'm getting help from Andreas Carlson, Andre Berodin from the hackers thing. and there's a couple other people, Andre Lepekov, I believe saying all these names is hard. I call them together, the Andres. All three people I work with are called Andre Great.

Anyways, but yeah, so the Google Summer of Code initiative is for that purpose. And we actually, with Nick, because of all the hacking, we actually had five or six projects. And this was by far the hardest project. This was fixing a 30-year-old Postgres problem that was too hard for the original PhDs who wrote the paper, Yao at all, and Shannon later on how we actually handle our bee tree stuff. So it left behind this gaping hole. And I'm one of these people. I have not as much programming in Postgres world, but I've been chief architect of software and doing software since I was a teenager professionally. So for me, once I got access to AIs and then a good programmer like Selma,

I'm like, the world is my oyster. And then, of course, you learn their lessons from there. Yeah, calling this a big project, I think, might still be understating it. This is a huge, ambitious undertaking. But let's come back to that, because I wanted to hear from Salma as well. Just from the basics, what made you interested in doing Google Summer of Code? Why Postgres? Were you looking for a project this big? From your perspective, what's it being like?

I was interested in databases. I was studying the senior course as its database introduction. to database. It's from university CVU, but it's online. And I was working on a project implementing B++ project. It's the database, the learning system, they are, we have a project. We implement its parts. And also, I know Saldi preferming my university who got accepted the BUSORIF code last year. So I wanted to check what's going on from this work. And the two, I the organizations and then when I found Postaggress sequence I found a project about the P plus 3 and I found it interesting then I didn't know anything about the internal

the Postgres at that point but I sent Kirk an email asking about what should I do first how should I prepare if my knowledge and my level is good for this project and he responded was the hacking sessions. He, Andre and Nick, ha. And I watched the sessions and asked him again and sent another email asking questions about pet trees and the blood problems,

the ideas they discussed and the videos. And that's when everything started. We kept talking back and forth until he started in May. Yeah. So it sounds like a match made in heaven. Kirk's crazy enough to suggest a project this huge and ambitious, and you're crazy enough to be interested in it.

Okay, I start in sight and see how this is working. So there's some magic truth into that. I've been running and managing developers for the last 30 years, and one of the secrets I've learned in managing developers is you only give them enough information that helps their confidence, and you hide the things they're going to run into and to the future until they get there. otherwise you overwhelm them and they give up. And having such a, let's say, naive student was so helpful in the beginning as she just learned last week.

So, yes. There is definitely, I can definitely see that, that there are benefits to that side of things. But it reminds me of that, I don't know if it's a meme or something, or maybe just a post that was just funny. It's something like, we don't do this because it's easy. We do it because we thought it would be easy. Something like that. Yes. Exactly.

And if you want, I can give you the, this is the cool part. And this is my kind of metaphor for helping everyone understand what's going on. All right. Fixing a B tree and doing B tree merge and page merging and keeping it perfectly clean is absolutely well studied. And it's easy in a single user environment with only one thread that does the reading and writing. Okay. The only thing that makes this complicated is that you have potentially 10,000 other people reading the same structure while you're changing it. And the magic, and this is the part that we had to understand, the magic is simply, first, we are limited in how big of changes we can make at every step so that anybody who notices the change can self-correct.

and then next is to turn it into the small number of steps into the future until eventually all the changes are made and the bee tree is back to normal and you didn't break anybody who's out there running because you can't break a search you can't break an insert you can't break a delete if you break these things obviously you're breaking them in other threats so that's the only thing that makes it hard if we could just do it and do it all on our own for example if we could actually send a message to everyone's scanning an index right now and say stop, restart after I'm done, and then we make the changes and push them, that would be easy. But imagine having a 30-minute query get stopped and have to restart. That would be horrible implementation. Hey, Nick. Hello, hello. Yeah, apologies for being late.

It's his first time so much. Good to have you here. I think we should even, maybe we could go back a step and look at why, even bother now? Like Postgres has got this far without Btree merge. It could conceivably continue for quite some time without it. Like what problems is it causing and why the existing ways of handling that maybe not sufficient?

Or why, if this is such a big undertake on such a difficult thing, the payoff must be big too, right? Like what's the benefit? Yeah, so to say the payoff must be big too, two isn't necessarily the same thing. The people who need it the most are the people who can afford it the least. So, for example, this started because Andre Broden mentioned, they have a table that's so large at his company that if they do re-index concurrently, one index takes over 72 hours to re-index concurrently to get rid of this bloat, right?

So the thing is, and then there's also times, There's no getting rid of the bloat if it was a one-time set of deletes, and you're not doing a bunch of inserts back in the beginning part of the index. You're not cleaning that up. It's just going to stay there forever. So part of the problem is bloat, in fact, space usage. But every time you make space bigger, you also start impacting time, especially if it's empty space.

So now your searches take, you're reading more buffers. You're doing more work than you have to do to get and collect these things. So the first thing is, it was hard in the past. Very few people understood all of the complexity, and therefore they weren't willing to make the change. AI is available now that can explain all of this complexity better. And even a guy like me who's got 40 years' experience elsewhere, I can now come in and point that experience at a problem with the help of AI

and wrap my arms around it and go, oh, I see what the problem is. Everyone's trying to do it quickly. we need to do it slowly. And if we make the change slowly, then it's possible to do. What's the benefit? Postgres ends up with self-healing indexes.

That's how I refer to them. As you naturally, in fact, where does this cleanup belong? It belongs in vacuum and the delete code. When you delete records, it just marks them as deleted. When you actually remove them from there and you leave a page mostly empty, that's the logic we're writing. And they're going to be able to put that.

right back into vacuum and say, oh, let's push these tuples over here onto this very empty page already, and let's start the unlinked process. So the vacuum process, which already does a lot of work that Postgres counts on, can now pick this stuff up. And then we don't need the re-index. Go ahead. Nick. Let me explain my perspective. When I was studying B3 in school, 20 plus years ago, They told us books like Chris Day, Dachulman, other books. They told us that B3 is almost balanced, tree with a lot of children in each node, right? Almost balanced means that from root to leaf, it's always n or n plus 1. And there are algorithms that rebalance it when we insert data or remove data from leaves.

So it means that when you insert and usually when we have integer four, integer A, always on the right side, right? And when you insert and the right side, the leaf becomes already almost full, it's split, right? And then rebalancing happens. And vice versa, when we delete everything, some leaves are empty, rebalancing happens when leaves are being. deleted. But for me, some time ago it was a big surprise that only the first part is implemented in PostGbos. And only then realization came how actual index blow is happening. And we know there are optimizations in PostGus 13 and 14 for the duplication. But it's not solving that. As you mentioned, Kirk, if you update or delete

Especially if you delete, updates also like delete plus inserts, right? If you delete entries in leaves which are in the middle, the whole range, it creates basically empty space, right? And it stays there with a fun correction. In the heap, if whole page is empty, it will be truncated if it's at there. In B3, it will be truncated even if it's in the middle, right? But it should be fully empty, and this is rare. That's the magic.

Current Postgres only deletes a page from a leaf page if it's 100% empty. If it's 99.999, meaning there's just one record out of 8,000, it's going to hold that page open. And they don't want to go through the trouble of moving that one record. Yeah. How many references can be in a page? 8,000 it's a page size. Yeah, that's a page size. Yeah, but...

Yeah, anyway, so this is how blood and it cannot be removed by vacuum with just empty space, right? And this means that UUID version 4 has advantage over UUID version 7. No, hold it.

UUID 7 had the advantage. It went to the right. Oh, I get what you're saying, yes. Yeah, our normal way of thinking UID version 7 has advantage because data locality all fresh data stays in fewer pages.

But this also means if you integer 4 or integer 8 primary keys, delete the data in the middle leads to blow it and that's it. Without merge algorithm. And the UIG version 4 you have some chances to have

a new insert happening to the same leaf. Anyway, this is my understanding. It was a big surprise for me that PostGry doesn't have split. Not split, merch. Merge. Right?

And their argument, the other key point I want to make is because of the research I did and listening to hackers comment before. So you understand sometimes programmers justify their decisions after the fact. Okay. I'm a software developer. I confess, I've done this myself. Anyway, so one of the pieces of feedback I got from Bruce was, oh, they tested theoretically that merging at 50% empty just causes more pay. page splits. And I'm thinking to myself, what a straw man argument. Nobody, nobody in the right mind should take two 50% empty pages and merge them and create 100% full page. That's why we have

things like fill factor. Of course, that page is just going to split on the next insert. So, but yes, this gets back to the arguments against bothering to solve this problem. I think the problem has become easier to solve in today's world. Just to put the other perspective across a little bit. Like, I think I agree that it's good to, we should definitely approach new hard problems. Like, if we, someone's got to at some point, right, it makes sense. But this is like incredibly difficult part of the code.

It's B-tree indexes. It affects every Postgres installation out there. The risk of making mistakes is like really bad, right? We're moving things around in a B-tree. That means ordering matters. And, like, we can have corruption. We could miss entries in a scan and think there is. isn't data or we could see an entry twice and get duplicated data. So the like risk of it going

wrong is so high that like it has to be perfect. And it is it has to be like full proof like real solid. So then you have to say then what's the like if we're going to risk doing any solution to this like what's the benefit. So I think then we do have to come back to like how do we solve this currently. And I think Andre's 72 hour reindex index in that's concurrently must be. such a big table and like put on a big index as well right that it must be like an absolute outlier most big indexes still should be like in the order of tens of minutes or hours like like single digit hours I would have thought but and why have to okay so the downsides there are downsides right like you can only run one at a time you need the space again but like that's only

disk space right are talking about reindexing yeah yeah so reindexing index concurrently. It's been like, Horizon pinned. This is a key problem. Yeah. So you fight bloat in one index and cause a bloat in that database.

But there's like we've talked, Nick, we've talked many times about like this is a reason to partition or keep your table smaller. Like there are other design solutions around this area. So I think I've also personally seen indexes that were 99% bloat because of like access patterns. So you can get these extreme cases that you're talking about. I've seen it in real world workflows. Yeah, simplest example is when we have a long history of something like orders in e-commerce and then they decide to clean up. They don't need orders succeeding one year or two years.

They delete all that data, but since integer 8 or UUAD version 7 primary key, blood stays an index and the only way is to rebuild it. Yeah. So it's a simple example. Maybe I'm not right because if you delete whole data from the past. Imagine if customers on like a software as a service application, you delete all of their data because they leave the service and that removes like 80% of, like maybe they're a big customer leaves and 80% of every page goes.

Like that's a very easy way of removing it, moving a lot of every page, but not 100% of any one page. So I get that this problem, I do get that this problem exists, but I'm just, pushing back to say, is it as bad? By the way, to add to your case, it also pollutes the cash. I think that's a big deal, especially in the days of memory getting more expensive. There are other knock-on impacts of carrying all of this wasted space around. But I'm still of the opinion that the bar should be extremely high for attacking this.

Okay, I'll give you your argument temporarily. Let me give you the opposite side of our argument for how hard it turned out not to be. Now, granted, our patch isn't complete, but we had a working prototype in the first half of the Google Summer of Code project timeline. Okay. Let's wait. So should we switch to solution then? And Salma, do you want to talk us through? What was your approach?

Like, how did you go about designing this and why did you make certain design decisions? Okay. We had a lot of these questions. First, we had a lot of overtime and a lot of first ideas. Our first design idea was to merge two pages, two pages together. So we have a left page and the right page, and we move all data from the left page to the right one. And this is a left page as a direction, leaves the data in it, as a direction for backward scans. So when a scanner, when a scan read the right page, then it was waiting between the two pages,

and we merged these two pages together. Then after the merge happened, it landed on the lift page, which we moved its data. So our first idea was to keep the data in the lift page, so this backward scan can read it and go, or no need to recover, no need to do any scrub work. But when we proposed this to the hackers, they said that this is a corruption to the index because we have repeated data and it will cause a lot of problems. Also, when Vecium cleans the index,

so if it's going to clean these two or only clean the data or the right page. So Mewisker, try and find the leather, So the solution we are working on and we sent the first concept about hackers was instead of keeping the left page as being data on it, we only keep it only to route the scans, the forward and the backward scan to how to recover. When a scanner read the right page and it's about to read the read the lip bait, which is now at all this store, it doesn't bring any data.

Actually, the scan in this position have a scalar bait data, seeps and not ripoverridden yet. So this scandal bay contains the list of the TID, a list of TIDs from the right page trip before the merger actually happened. So we are using this, to save this TIDs in another list. So when we read the right page, we know which TIDs we read and which values we read and which we have it yet read.

So we go back, read the page again and eliminate all the values we haven't seen before, which are saved. So anything except the ones, So we're saved in the list we have. So again, what we called the original merged away page, we called those ghost records. They were ghost copies of the original records. And let's understand one thing.

If I have a hundred scans going on and I merge two leaf pages together and nobody notices because they were in different parts of the tree, does anyone care? No, because by the time they get to those pages, they'll be correct. There's just a tiny amount of time where we could actually do the merge while people are currently have these things read in memory and they're processing them waiting to read either the next or the previous page. And that's what Selma was talking about. So if we have scans that are touching the points that we're doing this to, those are the only ones we care about.

If there are one before it or one on the other side of it, we don't care about those scans because they'll be correct by the time our lock let's go. Unfortunately, for the guys who read in the page that were going to merge away, they read in and they processed four records off of that page. Then they read the next page. And now those

four records have already been added to that page. That would cause the error of duplicate records. We can't allow that. So, Selma explained, all we did was we kept in memory the records that we read from the previous page, the four that we accepted. And then

on this page, right as we go to process this, we know to save this because we detect the flag. And then when we read all these new records plus these four, we subtract these four off and only add the new records to our scan. And so the forward scan continues and it didn't miss a beat. And we do effectively the exact same thing in reverse for a backwards scan. That's the only special cases we have to worry about. Right at that edge case. And it's only when they're reading. So what did we do to reduce the risks? One, we'll only merge two leaf pages together. If you try to merge more than two, you introduce undetectable errors.

Everything we do, we should make detectable, and then we should handle. So by merging only two pages together, we limit how much we can actually fix, but at the same time, we limit what we can break to a known set. And that's then what we implement for the code. Next we make sure that these two leaf nodes are only pointed at from the same parent. So this way we don't have to repair the upper structure of the tree. This is another 90, 80, 20, 90-10 hack. Why are we doing it that way?

Because again, I don't want to repair anything more. I just want to work on these three nodes so that this way the two leaf pages can be turned into one. Everyone who used to point at this one will now point to this one. and slowly this page will become empty and disappear, just like a deleted page, but very slowly through the process. So by minimizing how much we do in any one amount of workload and focusing it correctly, what we do is we expose the surface area of the problems. And then our job is canceling Gretel. We got to drop enough candy or bits on these leaf nodes so that the scan.

hands can detect that, oh, this changed while I was standing on it. If it changed while I wasn't standing on it, I don't care. And then I can't fix it. I can do that small change. By the way, the next change it has to happen, I have to wait to the transaction ID of all transactions passes in time. The same way deleting a page goes from half dead to deleted, and then from deleted to free space. It has to wait that transaction ID passing in order for the next pass to work. And these are the baby steps, and that's when I compare it to trying to do road work and put up a detour.

If you want to put a detour on a road that's currently active without jamming the traffic, you have to let traffic still go through that's already on the road. You start backwards and put the detour flags the furthest ones out first and bring them in, and then you slowly start putting cones out there to force the truhrase. traffic to take the new path. Anybody who's caught in front of you, it's only those cars that you're dropping cones on in front of that have to react to this merge. Everyone else who comes after everything's in place, they'll end up on the detour. And then once you lift the detour away, and that's vacuum's job. Vacuum's job lifts all the cones away and it goes and picks up all

the detour flags. And now whoever was on the detour flag finishes and the rest of the people finish on the normal highway, and from that point forward, nobody notices. So I know major factors participated, like Peter Gagan and Robert Haas, others. And there was a big question, I understand, that how can you prove reliably some guarantees that everything will be correct always, even on all age and corner cases? Was this answered or not? We're still answering it, right? The answer is to keep the changes small

and to make sure all the different code detects those changes. They just identified a bug where in the middle of a B-tree merge, somebody did an extra delete. And the code coming in didn't detect the flag on the page that it was merged away. So it tried to process the page. But yes, there's pieces there. We're still going to have to solve.

What bothers me a lot is my eye is finding bugs in PostGy19 every day right now. And that's much easier. It's easier to find a bug than to prove reliably that there are no bugs. Isn't it fundamentally impossible to prove a negative? Well, that's why various theoretical foundations exist. It's proving something, like mathematics. This is the question they ask. like Peter Gaghan, right?

So some like ideally it would be okay, Postgis follows just those articles from 80s. Right, let's just based on that we know everything is fine. But there are nuances in current

implementation. It's impossible to like there is no full match obviously. There's we already just found a new limitation of our approach. It turns out there's two B-tree versions for file versions. There's an older version that doesn't support the flags we're using, and we can't do the merge on those bee trees, clearly.

So that's going to be one of the flags that we have. The real question becomes, simply, is the process sound? Does it set up the right locks and the pins in the right order? We've already got the logging working, where it's pushing out the wall log, and we can crash the server and recover it in the middle of the merge process, and then the vacuum on the other end can finish cleaning. it up. It's coming together and we're just past the halfway mark of Google Summer of Code. Now, that said, I'm not expecting this to get published by the time November rolls around and Google Summer of Code is done. We know that this is going to take longer. And part of it is, Nick, I'm expecting you to tell your AI super agents to go out there and crush this code

looking for the edge cases. Right. And the other side of this equation, is we'll never know it's perfect, right? At some point, we know it'll be well tested. Some proof is needed as I understand. This would be... I wanted to ask Salma, this is probably one of the hardest projects of Google Sam of Code.

I participated in Google Summer of Code in 2006, exactly 20 years ago, and since then I kept an eye on it. And this looks like most challenging in terms of how fundamental it is. How does it feel? from your side. I know guys like Robert Hass and Peter Geigen proposed to change the project, right? Because of complexity. How does it look so? Isn't it scary?

Yes, but from the start, Kirk told me this is already the problem and we will not have it done me with the end of the movie sphere of code. It's hard about, I truly, I'm probably I want to see it make progress and hackers have their insights on it and their views. We do a lot of work on it. It's a little bit hard, not a little bit, but it's not that hard, like, I'm scared of it. Also, understand, I think I mentioned this with you, Nick, and Selma knows this. What's our definition of success when it comes to Google Summer of Code being done? Is it that this gets published, accepted, and there's confetti in the streets?

No. Okay? My definition of success is we've defined a language by which we can now talk about making this happen in the future. Meaning we've identified the core issues. We can talk about it. Next, we started quantifying the impact on performance from the standpoint of how much is it really slowing down every beach. tree search, look, if it's going to cost every B3 search 20% efficiency, like, no, let's not do this to answer Michael's question, right? If this isn't a very small delta hit on searching, then it's

not worth it. But on the other hand, if we don't develop the language, we don't develop the protocols for testing it for performance. We don't develop the process by which people can discuss it and review it. If we get all that done, I think, this is a huge successful Google Summer of Code project in my opinion. And if we have that plus a rough working prototype, hallelujah, that's something we can carry forward and maybe it falls on to much more experienced people than us just to make sure of the correctness. But I'll be honest. That was the limited version that I, that kept me motivated. As we've made the progress we've made, my understanding of these bee trees and why they made the decisions they made has skyrocketed.

And I'm becoming more and more confident in our approach because I'm starting to really understand what it is we have to do, what those breadcrumbs are. Now, is there a lot of testing involved? Absolutely. Could this affect third-party tools that work on indexes? Absolutely. if they don't know what a merged away page is or a merged page and they're not looking for that stuff, they could make mistakes. Absolutely. We don't want that to happen either. But on the flip side,

core never worries about the extensions per se. It's the extension's job when that version comes out to be up to date. I don't want to worry too much about it, but I honestly think we're close. We have the core concepts in place. That's the part I'm impressed with. Also, it's a very beginning, And there is tuned to me in our first meeting, but it's not only about completing this project, it's about getting me able to contribute to Westergris. So it's, I will just take it to Wastogis to them to contribute to Newstabstis. Yeah, that's great. That's great. So how many months left is you mentioned, Kirk mentioned in November, right?

I think it's, yeah, it's the beginning of the November. Since it's already not much time left, what should we expect in terms of prototyping this thing? So the way that we did this to get it working was, as we read the next page, if we detected we were stepping in the middle of a quagmire, meaning the change happened under our feet, we could just reach back in memory, look at the records we just added and apply a fix-up algorithm. That was completely working. And we had the stuff working inside a vacuum. So that was good. What we found is parallel scans would not work this way because you'd have to pass all of the TIDs from the previous read

to a different thread. And all of that messaging would just destroy the parallel thread. So what we've done is we backed up the truck and we reanalyzed the situation. And we realized all we really need is the one pivot tuple. So on a forward side, scan, we need the last tuple on the page that we're going to merge away. And on the backwards scan, we need the first tuple of that page. So we know what to pre-process if we reread that page.

So let's do backwards scan. I just did this page, our right page, before the merge happened. And I know the first tuple, and even in a parallel scan, this is great. I go and I read the next page backwards, and it was merged away. That flag tells me I have to go back and reread the merged page into, but I only process the records that are less than that current record that we saved from the previous page. Those are all the ones that were inserted because we only move the keys to the right in the tree. And they're sorted, which is beautiful. And they're sorted uniquely because the last sort key is the TID, the row ID in the table. So now we pull that up.

We reread that page. We strip off everything we don't want to read again that we already read, and we just add the remaining records in. So now with this change, we have to go back and rewrite our existing routine. But now that means we now have parallel scan will be working shortly. And I'm thinking within a week or so, parallel scan will be working, and the normal scan will be working using this new logic. Which means at this point, we have the wall logging, parallel scan, regular scan and the core handling. Now we have to find the nuanced places,

the delete records, update records, things like this, that touch these pages, and we have to find the other touch points to make sure that they're honoring the new flags we've created in these things. Once we're done with that, it's looking good. But in the next week or two, I believe Salma, and I'm speaking for you, Salma,

you can chime in. How long do you think it's going to take you to rewrite all of that code you spent months on I'm giving you two weeks so far. Go ahead. Tell me how wrong I am. I hope it's done before two weeks, but yes. Now you know why I love her.

So you mentioned with wall logging. What's left then? Wall is very difficult. It's, it was only difficult, correct me if I'm wrong. The difficult part of Wall was, first off, it's a complete mind change in the problem you're solving. because now you're working on playback and capturing stuff. And then the testing required that Selma had to learn how to set up a wall transfer and a recovery process and do all that.

Other than that, what do you think on the wall logging stuff in making sure that it worked? Salma, what was hard? No thing we were titular, but we had to add an new MB3 tree, a resource manager, because the inventory only had one slot left, the left slot. And we needed three slots for logging. One slot for logging the merge, and two, for when vacuum cleaning the way page, and we're cleaning the website page.

So we needed three. First, we did it with multiplexing this one year's slot, but it wasn't clean. So we asked on the scourge that I can do another, a new resource manager. And we did a new MBG2, like following ZAHIP, which is already introduced. And for those who are not up on that new resource manager, effectively wall is blocks of data. When you read in a wall block, there's a bunch of flags that tell you how to interpret that data. That's the resource manager layer of it.

is it looks and says, oh, this is a bee tree wall. In this case, it's a bee tree merged away wall record. Right? So it has to know how to read this in and process it. And we had to teach it that by adding our new types in. I somehow haven't followed a project recently and missed that wall is already being in work. Yeah.

I'm impressed. I'm impressed. So if everything goes well, what will be left? besides a theoretical question that everything is reliable, which is tiny question. Quite a big deal. Yeah. What will be left? Besides the question of, is it correct?

What will be left? Honestly, it's the things we just talked about, right? It is literally the parallel scan and getting that in there, plus finding other touch points or edge points. And then in my book, the next layer is performance testing and having. you send your guys at it? Actually, now once we talked through all this, I have it's a great idea

to point my new harness to find those bucks like I'm pretty sure we will find some. It won't prove the ethical correctness of everything, but it may be to help a little bit. My question is what will be left

to feel the prototype complete. If all is there, what else left? think? Well, this last two-week cycle is going to be most of it, and then getting people to give us feedback and testing. That's what I want this broadcast to talk about, because this is, I think this is the UUIDV-7 of Google Summer of Code. In PG-18, that was the one feature everyone understood. It's all. That teacher was simple. It was. And you need to make efforts to use it. Unlike this feature, which is hard and everyone is supposed to use.

benefit from it by default. So I understand why you say this, but this is, for me, it's quite opposite. And this podcast I wanted to do because this is the most impressive Google Samav Code I saw in 20 years as I feel it. It's like taking articles from 80s,

using AI, attacking a hard problem. And it definitely deserves attention. I definitely will point my harness to find bugs. we need people to actually be looking at this and giving us feedback. Yeah, I actually wanted to commend you for the amount of interest you'd already got. The level of detail that people have given comments and advice already from senior people and people that have worked on Beatry deletion in the past as well,

it's been incredible. But I think I'm a bit confused because I think some of their feedback, I can't tell if it's been addressed yet. So I saw one comment from Peter saying what it boils down to is the same TID must never exist in any two index two. That was the ghost records. That was the issue with ghost records. So that's no longer true? Yeah, we don't do it that way anymore.

We fixed that. It became an invariant and they didn't even appreciate the fact that nobody's supposed to look at those records except the people that are getting their toes stepped on in the scan. Everyone else further from the scan would never look at it. them. These people, and they, they blasted it, which it's okay because the technique that Selma came up with is actually more efficient. So I appreciate the feedback, but keep going. If there's other feedback, but for the most part, most of these things have been answered. Yeah, I think that's the kind of thing, though, that does help, not prove an issue can't exist, but as soon as you allow for two TIDs to point to this, like, as soon as you allow for two records to point to the same TID, you

introduce the possibility of corruption. So I do think that's the kind of design decision that helps avoid whole categories of bug, which is quite nice. Salma, did you have to modify M-check? Oh, yes. Yeah, we

have to let us know about the merited away page. And most too, a lot of, a lot of the code, most part of the core. Read the high from pages and and we don't have attention. Yeah, we don't

pay attention to the residual way bait. So we have to tell a lot of the words of the code that to skip the military page, the same way it does with the deleted baits. Or half dead. Yep. Yes. Perfect. But no, back to your point.

So not only did we get feedback we had to fix AM check, but then after she fixed it, by teaching it how to recognize our pages, but then it came back and said, no, you cheated. You didn't teach it how to inspect your pages to make sure they're actually correct. And so Selma went and worked on that.

And so let's be clear. We are standing on the shoulders of everybody in the Postgres community. And this kind of feedback is helpful for us. Yeah, we bit off way more than we could chew by ourselves. And if we were alone stranded on a desert island with a cray supercomputer and an AI, I don't think we're going to get near the best result we get by interfacing and working with the community. Nice, yeah, agreed. We just got an email.

Someone reviewed and pointed out a bug we need to fix. And this is also the kind of review we need because it pointed out to some part of the vacuum that I didn't know it existed. So, yeah, it helps a lot to point out to this. I would also check maybe just a TAPO extension and some other extensions. Yeah, I'm definitely pointing my harness after

I'm done with my bugs if I'm done with bugs because they keep... Squeeze this in between the big runs on the bugs. Sounds good. Yeah, sounds good. Great. I'm very impressed with progress. I was

expecting like attacking only part of it. but it's obviously the attack of the whole thing. It's impressive, especially. So Michael, with all that, are you as nervous now as you were at the beginning? I think the closer you two get to something committable, the more nervous I'll be. So don't treat my nervousness as any kind of sign of your program. But I would agree that this is a really impressively ambitious project.

And if it's about learning and inspiring people to become committers or contributors in the future, I think you've succeeded. And we wanted to talk about it, right? It's an interesting enough piece that we wanted to talk about it here. So I'm really pleased that you're attacking this. I think you've set expectations well on the chance of getting anything committed here. But it sounds like you two are getting dangerously close. So I should be worried.

But that's a compliment, right? The fact that I was worried when senior hackers were making changes to B-tree code in 13-14, turned out some of it was like the best work I've ever seen. 14.0, you remember this? I remember the, yeah, but that was slightly different code, right? Like the re-index concurrently stuff, yeah. But the bottom-up deletion that it was Peter Gagan as well, that is another attempt at trying to avoid the problem in the first place,

of B-3 bloat, but without having to worry about merging. So it was trying to avoid spitting from the other side of it. I was so impressed by that work, I'm really impressed that there weren't major issues with it. So it's this kind of super scary stuff that touches everything. They're the changes I like the most because everybody benefits without having to do anything, but they're the changes I find most scary because everybody's affected without having to do anything. So, yeah, it's impressive that you've even taken this on. And I'm really impressed with your progress and the feedback you've got.

And hopefully, Salma, the whole point was to get you interested in contributing to Postgres, and it sounds like you are. Thanks. I know about other plans, right? Not only about this complex project, but maybe smaller features and fixes and so on. That's great. Salma's kind of found a sponsor, and she's in the background also picking up some of our LSN drop table logging and some of the other hackers stuff that Andre and Nick and I are doing in the,

side and she's going to help push some of those through because we just keep coming up with new ideas and we don't babysit the old ones to all the commit fest right and there's a lot of work there so she's picking up some extra work and skills and doing that as well it's time to start joining our sessions on yeah hiking sessions in youtube oh look at that right yeah so to wrap up let's maybe repeat to what people can do to help just review the patch, tested, find bugs, and so on, right, and spread the word. Also, we have a playground in terms of visualization to play at the Lodov-Bulta. So, yeah, check out the visualizations.

They're still accurate for now. I'll update them in two weeks when we get the patch. But at least go through and do a plus one if you like the idea that we're working on it, Michael. Anybody else? Okay, plus one these, because the more replies people get and see in the hackers' email chain, the more likely they're going to crack it open and take a look at what's going on. And we want that attention. Again, we admit it may not get committed, but the flip side is that the more people that look at it and realize that this is not crazy, the more it helps us. So those are the key things we need.

We just need that extra attention, whatever anyone else there can do. And again, I want to say kudos to Google summer of code, because this wouldn't have happened if it wasn't for that. It's my first time mentoring. I feel bad for Salma, but I did my best. No, you are a great mentor. Great. Thank you for coming. It was interesting. It's very challenging and super interesting project. I'm reaching for it and I'm going to help when I can. Thank you. Awesome. Thank you guys. Have a good day. Thank you. Likewise, congrats. Good to meet you both. Bye.