Re: Extensible Rmgr for Table AMs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id 20220404043337.ocjnni7hknjsibhg@alap3.anarazel.de
Whole thread Raw
In response to Re: Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Hi,

On 2022-03-31 14:20:51 -0700, Jeff Davis wrote:
> If you are still concerned, I can switch back to separate tables to
> eliminate the indirection for built-in rmgrs. Separate rmgr tables
> still require a branch (to decide which table to access), but it should
> be a highly predictable one.

I still think the easiest and fastest would be to just make RmgrTable longer,
and not const. When registering, copy the caller provided struct into the
respective RmgrData element.  Yes, we'd waste a bit of space at the end of the
array, but it's typically not going to be touched and thus not be backed by
"actual" memory.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
Next
From: Tom Lane
Date:
Subject: Race condition in server-crash testing