| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | alvherre(at)kurilemu(dot)de |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: table AM option passing |
| Date: | 2026-04-02 05:39:43 |
| Message-ID: | 4287.1775108383@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2026-Apr-01, Antonin Houska wrote:
> I realized that patch 0003 is doing two different things, and they
> should each be their own patch which can be rejected if we don't like
> them; so I split it in two. One moves the heapam.h-private bit to the
> 32th bit.
I'm sorry I haven't recalled yesterday, but this technique resembles the
DSM keys in parallel.c:
/*
* Magic numbers for per-context parallel state sharing. Higher-level code
* should use smaller values, leaving these very large ones for use by this
* module.
*/
#define PARALLEL_KEY_FIXED UINT64CONST(0xFFFFFFFFFFFF0001)
...
What I found inspiring here is that the "core" uses the high bits while users
of the API use the lower ones. Perhaps it'd be appropriate in v6-0001 to
reserve the high bits for the TABLE_ options and leave the lower ones for the
HEAP_ options. If someone implements a new AM (possibly as an extension), it
should be more comfortable for him.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-04-02 05:45:21 | Re: Initial COPY of Logical Replication is too slow |
| Previous Message | Amit Kapila | 2026-04-02 05:28:24 | Re: Initial COPY of Logical Replication is too slow |