Move syncscan.c?

Started by Thomas Munroalmost 6 years ago3 messageshackers
Jump to latest
#1Thomas Munro
thomas.munro@gmail.com

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.

Attachments:

0001-Move-syncscan.c-to-src-backend-access-table.patchtext/x-patch; charset=US-ASCII; name=0001-Move-syncscan.c-to-src-backend-access-table.patchDownload+33-12
#2Andres Freund
andres@anarazel.de
In reply to: Thomas Munro (#1)
Re: Move syncscan.c?

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

#3Thomas Munro
thomas.munro@gmail.com
In reply to: Andres Freund (#2)
Re: Move syncscan.c?

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.