On 2026-Jun-02, Mingwei Jia wrote: > diff --git a/src/backend/storage/map/map.c b/src/backend/storage/map/map.c > new file mode 100644 > index 0000000000..563f38b21a > --- /dev/null > +++ b/src/backend/storage/map/map.c > @@ -0,0 +1,162 @@ > +/*------------------------------------------------------------------------- > + * > + * map.c > + * Umbra metadata-fork disk layout helpers. > + * > + * This file contains address-translation and in-page access routines for the > + * metadata fork disk layout. > + * > + * src/backend/storage/map/map.c > + * > + *------------------------------------------------------------------------- > + */
I find this pretty difficult to understand, and I think it's because the fork system is the wrong abstraction. The current system is too obviously centered around heapam and nbtree, to the detriment of everything else. I would like a system whereby each (index, table) AM can determine which forks exist and how to deal with each. For instance, BRIN indexes have a "revmap" at the start of the main fork; when it needs one more "revmap" page but it's already used by regular index tuples, it needs to move all those existing index tuples to another page so that the page can be used as a revmap page (I think this is called "evacuate"). That's absurd and overcomplicated. If the revmap had its own fork, a bunch of code and locking considerations would go simply away. I think that would also apply to this map thingy you want to create (although I can't claim to have really understood what you're trying to achieve). Anyway, if I'm pointing in roughly the right direction, then I don't like the idea of this new smgr creating yet another layer to paper over that failed abstraction. Let's fix that instead. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
