From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | 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-02-03 05:34:18 |
Message-ID: | 20220203053418.lj5lzsp7yf2mvspw@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-02-03 05:35:10 | Re: Design of pg_stat_subscription_workers vs pgstats |
Previous Message | Fujii Masao | 2022-02-03 04:59:03 | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |