Horton

Thread

Commits

  1. ExtendBufferedWhat -> BufferManagerRelation.

  2. bufmgr: Introduce infrastructure for faster relation extension

  1. Rename ExtendedBufferWhat in 16?

    Thomas Munro <thomas.munro@gmail.com> — 2023-08-12T00:29:05Z

    Hi

Commit 31966b15 invented a way for functions dealing with relation
extension to accept a Relation in online code and an SMgrRelation in
recovery code (instead of using the earlier FakeRelcacheEntry
concept).  It seems highly likely that future new bufmgr.c interfaces
will face the same problem, and need to do something similar.  Let's
generalise the names so that each interface doesn't have to re-invent
the wheel?  ExtendedBufferWhat is also just not a beautiful name.  How
about BufferedObjectSelector?  That name leads to macros BOS_SMGR()
and BOS_REL().  Could also be BufMgrObject/BMO, ... etc etc.

This is from a patch-set that I'm about to propose for 17, which needs
one of these too, hence desire to generalise.  But if we rename them
in 17, then AM authors, who are likely to discover and make use of
this interface, would have to use different names for 16 and 17.

  2. Re: Rename ExtendedBufferWhat in 16?

    Andres Freund <andres@anarazel.de> — 2023-08-16T22:49:49Z

    Hi,

On 2023-08-12 12:29:05 +1200, Thomas Munro wrote:
> Commit 31966b15 invented a way for functions dealing with relation
> extension to accept a Relation in online code and an SMgrRelation in
> recovery code (instead of using the earlier FakeRelcacheEntry
> concept).  It seems highly likely that future new bufmgr.c interfaces
> will face the same problem, and need to do something similar.  Let's
> generalise the names so that each interface doesn't have to re-invent
> the wheel?  ExtendedBufferWhat is also just not a beautiful name.  How
> about BufferedObjectSelector?  That name leads to macros BOS_SMGR()
> and BOS_REL().  Could also be BufMgrObject/BMO, ... etc etc.

I like the idea of generalizing it.  I somehow don't quite like BOS*, but I
can't really put into words why, so...


> This is from a patch-set that I'm about to propose for 17, which needs
> one of these too, hence desire to generalise.  But if we rename them
> in 17, then AM authors, who are likely to discover and make use of
> this interface, would have to use different names for 16 and 17.

Makes sense to me.

Greetings,

Andres Freund

  3. Re: Rename ExtendedBufferWhat in 16?

    Thomas Munro <thomas.munro@gmail.com> — 2023-08-16T23:31:27Z

    On Thu, Aug 17, 2023 at 10:49 AM Andres Freund <andres@anarazel.de> wrote:
> On 2023-08-12 12:29:05 +1200, Thomas Munro wrote:
> > Commit 31966b15 invented a way for functions dealing with relation
> > extension to accept a Relation in online code and an SMgrRelation in
> > recovery code (instead of using the earlier FakeRelcacheEntry
> > concept).  It seems highly likely that future new bufmgr.c interfaces
> > will face the same problem, and need to do something similar.  Let's
> > generalise the names so that each interface doesn't have to re-invent
> > the wheel?  ExtendedBufferWhat is also just not a beautiful name.  How
> > about BufferedObjectSelector?  That name leads to macros BOS_SMGR()
> > and BOS_REL().  Could also be BufMgrObject/BMO, ... etc etc.
>
> I like the idea of generalizing it.  I somehow don't quite like BOS*, but I
> can't really put into words why, so...

Do you like BufferManagerRelation, BMR_REL(), BMR_SMGR()?

Just BM_ would clash with the flag namespace.

> > This is from a patch-set that I'm about to propose for 17, which needs
> > one of these too, hence desire to generalise.  But if we rename them
> > in 17, then AM authors, who are likely to discover and make use of
> > this interface, would have to use different names for 16 and 17.
>
> Makes sense to me.

Does anyone else want to object?  Restating the case in brief: commit
31966b15's naming is short-sighted and likely to lead to a
proliferation of similar things or a renaming in later releases.

  4. Re: Rename ExtendedBufferWhat in 16?

    Peter Geoghegan <pg@bowt.ie> — 2023-08-16T23:33:58Z

    On Wed, Aug 16, 2023 at 4:32 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Does anyone else want to object?  Restating the case in brief: commit
> 31966b15's naming is short-sighted and likely to lead to a
> proliferation of similar things or a renaming in later releases.

+1 to proceeding with this change.

-- 
Peter Geoghegan

  5. Re: Rename ExtendedBufferWhat in 16?

    Andres Freund <andres@anarazel.de> — 2023-08-17T00:42:33Z

    On 2023-08-17 11:31:27 +1200, Thomas Munro wrote:
> On Thu, Aug 17, 2023 at 10:49 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2023-08-12 12:29:05 +1200, Thomas Munro wrote:
> > > Commit 31966b15 invented a way for functions dealing with relation
> > > extension to accept a Relation in online code and an SMgrRelation in
> > > recovery code (instead of using the earlier FakeRelcacheEntry
> > > concept).  It seems highly likely that future new bufmgr.c interfaces
> > > will face the same problem, and need to do something similar.  Let's
> > > generalise the names so that each interface doesn't have to re-invent
> > > the wheel?  ExtendedBufferWhat is also just not a beautiful name.  How
> > > about BufferedObjectSelector?  That name leads to macros BOS_SMGR()
> > > and BOS_REL().  Could also be BufMgrObject/BMO, ... etc etc.
> >
> > I like the idea of generalizing it.  I somehow don't quite like BOS*, but I
> > can't really put into words why, so...
> 
> Do you like BufferManagerRelation, BMR_REL(), BMR_SMGR()?
> 
> Just BM_ would clash with the flag namespace.

I like BMR better!

  6. Re: Rename ExtendedBufferWhat in 16?

    Thomas Munro <thomas.munro@gmail.com> — 2023-08-17T03:35:15Z

    On Thu, Aug 17, 2023 at 12:42 PM Andres Freund <andres@anarazel.de> wrote:
> I like BMR better!

Thanks Andres and Peter.  Here's a version like that.  I hesitated
about BufMgrRelation instead, but neither name appears in code
currently and full words are better.  In this version I also renamed
all the 'eb' variables to 'bmr'.

If there are no more comments or objections, I'd like to push this to
16 and master in a day or two.