On Thu, Jul 24, 2025 at 7:52 PM Tomas Vondra <to...@vondra.me> wrote: > Yeah, I forgot about that. Should be fixed in the v2. Admittedly I don't > know that much about nbtree internals, so this is mostly copy pasting > from verify_nbtree.
As long as the scan only moves to the right (never the left), and as long as you don't forget about P_IGNORE() pages, everything should be fairly straightforward. You don't really need to understand things like page deletion, and you'll never need to hold more than a single buffer lock at a time, provided you stick to the happy path. I've taken a quick look at v2, and it looks fine to me. It's acceptable for the purpose that you have in mind, at least. > Yeah, probably. And we'll probably test on such uniform data sets, or at > least we we'll start with those. But at some point I'd like to test with > some of these "weird" indexes too, if only to test how well the prefetch > heuristics adjusts the distance. That makes perfect sense. I was just providing context. > I have a very good reason why I didn't do it that way. I was lazy. But > v2 should be doing that, I think. I respect that. That's why I framed my feedback as "it'll be less effort to just do it than to explain why you haven't done so". :-) > Yeah, this interface seems useful. I suppose it'll be handy when looking > at an index scan, to get stats from the currently loaded batches. In > principle you get that from v3 by filtering, but it might be slow on > large indexes. I'll try doing that in v3. Cool. -- Peter Geoghegan
