| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, 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-03-24 04:43:08 |
| Message-ID: | 211518ee10e5c37014d3a11d744c1aadc43e9f2c.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2022-02-04 at 22:56 +0800, Julien Rouhaud wrote:
> > Right, which I guess raises another question: if the maximum is
> > UINT8_MAX, which BTW I find perfectly reasonable, why are we not
> > just
> > defining this as an array of size 256? There's no point in adding
> > code
> > complexity to save a few kB of memory.
>
> Agreed, especially if combined with your suggested approach 3 (array
> of
> pointers).
Implemented and attached. I also updated pg_waldump and pg_rewind to do
something reasonable.
Additionally, I now have a reasonably complete implementation of a
custom resource manager now:
https://github.com/citusdata/citus/tree/custom-rmgr-15
(Not committed or intended to actually be used right now -- just a
POC.)
Offline, Andres mentioned that I should test recovery performance if we
take your approach, because making the RmgrTable non-const could impact
optimizations. Not sure if that would be a practical concern compared
to all the other work done at REDO time.
Regards,
Jeff Davis
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Extensible-rmgr.patch | text/x-patch | 15.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2022-03-24 04:49:24 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
| Previous Message | Etsuro Fujita | 2022-03-24 04:34:58 | Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit |