From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Move syncscan.c? |
Date: | 2020-06-23 18:28:52 |
Message-ID: | 20200623182852.ywq4w7kxqbbsokpq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-06-23 18:29:32 | Re: Assertion failure in pg_copy_logical_replication_slot() |
Previous Message | Robert Haas | 2020-06-23 18:27:47 | Re: [HACKERS] Custom compression methods |