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

From Jeff Davis
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id 211518ee10e5c37014d3a11d744c1aadc43e9f2c.camel@j-davis.com
Whole thread Raw
In response to Re: Extensible Rmgr for Table AMs  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Extensible Rmgr for Table AMs
List 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

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors