| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Extensible Rmgr for Table AMs |
| Date: | 2022-04-04 04:33:37 |
| Message-ID: | 20220404043337.ocjnni7hknjsibhg@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-04-04 04:50:27 | Race condition in server-crash testing |
| Previous Message | Julien Rouhaud | 2022-04-04 04:30:20 | Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN |