Re: Why is pq_begintypsend so slow?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jack Christensen <jack(at)jncsoftware(dot)com>, David Fetter <david(at)fetter(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why is pq_begintypsend so slow?
Date: 2024-02-18 01:59:55
Message-ID: 20240218015955.rmw5mcmobt5hbene@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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 Content-Type Size
v3-0001-stringinfo-Move-more-functions-inline-provide-ini.patch text/x-diff 13.8 KB
v3-0002-stringinfo-Remove-in-core-use-of-appendStringInfo.patch text/x-diff 16.7 KB
v3-0003-WIP-Annotate-palloc-with-malloc-and-other-compile.patch text/x-diff 1.5 KB
v3-0004-pqformat-Move-type-sending-functions-inline-add-p.patch text/x-diff 4.6 KB
v3-0005-copy-Use-appendBinaryStringInfoNT-for-sending-bin.patch text/x-diff 1.9 KB
v3-0006-Use-pq_begintypsend_with_size-in-a-number-of-send.patch text/x-diff 3.9 KB
v3-0007-wip-make-send-calls-in-printtup.c-cheaper.patch text/x-diff 2.8 KB
v3-0008-wip-make-in-out-send-recv-calls-in-copy.c-cheaper.patch text/x-diff 20.7 KB
v3-0009-inline-pq_sendbytes-stop-maintaining-trailing-nul.patch text/x-diff 2.2 KB
v3-0010-heavy-wip-Allow-string-buffer-reuse-in-send-funct.patch text/x-diff 7.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-02-18 02:19:08 Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);
Previous Message jian he 2024-02-18 01:48:27 Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);