Re: Why is pq_begintypsend so slow? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Why is pq_begintypsend so slow?
Date
Msg-id 20240218015955.rmw5mcmobt5hbene@awork3.anarazel.de
Whole thread Raw
In response to Re: Why is pq_begintypsend so slow?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Why is pq_begintypsend so slow?
List pgsql-hackers
Hi,

I was reminded of the patchset I had posted in this thread by
https://postgr.es/m/679d5455cbbb0af667ccb753da51a475bae1eaed.camel%40cybertec.at

On 2020-07-31 13:35:43 -0400, Robert Haas wrote:
> On Fri, Jul 31, 2020 at 1:00 PM Andres Freund <andres@anarazel.de> wrote:
> > > Perhaps we could add a comment about this, e.g.
> > > Marking these pointers with pg_restrict tells the compiler that str
> > > and str->data can't overlap, which may allow the compiler to optimize
> > > better when this code is inlined. For example, it may be possible to
> > > keep str->data in a register across consecutive appendStringInfoString
> > > operations.
> > >
> > > Since pg_restrict is not widely used, I think it's worth adding this
> > > kind of annotation, lest other hackers get confused. I'm probably not
> > > the only one who isn't on top of this.
> >
> > Would it make more sense to have a bit of an explanation at
> > pg_restrict's definition, instead of having it at (eventually) multiple
> > places?
> 
> I think, at least for the first few, it might be better to have a more
> specific explanation at the point of use, as it may be easier to
> understand in specific cases than in general. I imagine this only
> really makes sense for places that are pretty hot.

Whenever I looked at adding these comments, it felt wrong. We end up with
repetitive boilerplate stuff as quite a few functions use it. I've thus not
addressed this aspect in the attached rebased version.  Perhaps a compromise
would be to add such a comment to the top of stringinfo.h?


> > Ah, I misunderstood. Yea, there's no reason not to do that.
> 
> OK, then I vote for that version, as I think it looks nicer.

Done.

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: "zwj"
Date:
Subject: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)
Next
From: Li Japin
Date:
Subject: Re: Thoughts about NUM_BUFFER_PARTITIONS