Обсуждение: Move syncscan.c?
Hi, It's a bit odd that syncscan.c is used by both heapam.c and tableam.c, and provides a generic block-synchronization mechanism that other table AMs might want to use too, but it lives under src/backend/access/heap. It doesn't actually do anything heap specific (beyond being block-oriented), and it's weird that tableam.c has to include heapam.h. Perhaps we should move the .c file under src/backend/access/table, as attached. I suppose it's remotely possible that someone might invent physical-order index scans, and once you have those you might sync scans of those too, and then even table would be too specific, but that may be a bit far fetched.
Вложения
Hi, On 2020-06-23 13:30:39 +1200, Thomas Munro wrote: > It's a bit odd that syncscan.c is used by both heapam.c and tableam.c, > and provides a generic block-synchronization mechanism that other > table AMs might want to use too, but it lives under > src/backend/access/heap. It doesn't actually do anything heap > specific (beyond being block-oriented), and it's weird that tableam.c > has to include heapam.h. > > Perhaps we should move the .c file under src/backend/access/table, as attached. Sounds reasonable. I suspect there's a few more files (and definitely functions) that could be de-heapified. > I suppose it's remotely possible that someone might invent > physical-order index scans, and once you have those you might sync > scans of those too, and then even table would be too specific, but > that may be a bit far fetched. Hm. That'd be an argument for moving it to access/common. I don't really see a reason not to go for that? Greetings, Andres Freund
On Wed, Jun 24, 2020 at 6:28 AM Andres Freund <andres@anarazel.de> wrote: > On 2020-06-23 13:30:39 +1200, Thomas Munro wrote: > > I suppose it's remotely possible that someone might invent > > physical-order index scans, and once you have those you might sync > > scans of those too, and then even table would be too specific, but > > that may be a bit far fetched. > > Hm. That'd be an argument for moving it to access/common. I don't really > see a reason not to go for that? Ok, done that way. Thanks.