Horton

Re: Extensible Rmgr for Table AMs

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2022-02-01T23:38:32Z
Lists: pgsql-hackers 
On Tue, 2022-02-01 at 20:45 +0800, Julien Rouhaud wrote:
> On Tue, Feb 01, 2022 at 12:39:38PM +0800, Julien Rouhaud wrote:
> > 
> > Other than that the patch looks good to me, as you said we just
> > need a decision
> > on whether custom rmgrs are wanted or not.
> 
> One last thing, did you do some benchmark with a couple custom rmgr
> to see how
> much the O(n) access is showing up in profiles?

What kind of a test case would be reasonable there? You mean having a
lot of custom rmgrs?

I was expecting that few people would have more than one custom rmgr
loaded anyway, so a sparse array or hashtable seemed wasteful. If
custom rmgrs become popular we probably need to have a larger ID space
anyway, but it seems like overengineering to do so now.

Regards,
	Jeff Davis

Commits

  1. Fix off-by-one error in pg_waldump, introduced in 5c279a6d350.

  2. Fix another buildfarm issue from commit 5c279a6d350.

  3. Fix warning introduced in 5c279a6d350.

  4. Custom WAL Resource Managers.

  5. Make logical decoding a part of the rmgr.