|From:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|To:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>|
|Subject:||Re: introduce bufmgr hooks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thanks for taking a look.
On Tue, Aug 30, 2022 at 01:02:20PM +0900, Kyotaro Horiguchi wrote:
> smgr is an abstract interface originally intended to allow to choose
> one implementation among several (though cannot dynamically). Even
> though the patch intends to replace specific (but most of all) uses of
> the smgrread/write, still it sounds somewhat strange to me to add
> hooks to replace smgr functions in that respect. I'm not sure whether
> we still regard smgr as just an interface, though..
I suspect that it's probably still worthwhile to provide such hooks so that
you don't have to write an entire smgr implementation. But I think you
bring up a good point.
> As for the names, bufmgr_read_hook looks like as if it is additionally
> called when the normal operation performed by smgrread completes, or
> just before. (planner_hook already doesn't sounds so for me, though:p)
> "bufmgr_alt_smgrread" works for me but I'm not sure it is following
> the project policy.
Yeah, the intent is for this hook to replace the smgrread() call (although
it might end up calling smgrread()). I debated having this hook return
whether smgrread() needs to be called. Would that address your concern?
> I think that the INSTR_* section should enclose the hook call as it is
> still an I/O operation in the view of the core.
Okay, will do.
Amazon Web Services: https://aws.amazon.com
|Next Message||Daniel Gustafsson||2022-08-30 22:29:41||Re: Comma-separated predicates in simple CASE expressions (f263)|
|Previous Message||Tom Lane||2022-08-30 22:20:37||Re: Comma-separated predicates in simple CASE expressions (f263)|