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

From Julien Rouhaud
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id 20220203053418.lj5lzsp7yf2mvspw@jrouhaud
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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Feb 01, 2022 at 03:38:32PM -0800, Jeff Davis wrote:
> On Tue, 2022-02-01 at 20:45 +0800, Julien Rouhaud wrote:
> > 
> > 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.

I agree that having dozen of custom rmgrs doesn't seem likely, but I also have
no idea of how much overhead you get by not doing a direct array access.  I
think it would be informative to benchmark something like simple OLTP write
workload on a fast storage (or a ramdisk, or with fsync off...), with the used
rmgr being the 1st and the 2nd custom rmgr.  Both scenario still seems
plausible and shouldn't degenerate on good hardware.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
Next
From: Masahiko Sawada
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats