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

From Michael Paquier
Subject Re: Why is pq_begintypsend so slow?
Date
Msg-id ZdKGYI8x2EsHwaPn@paquier.xyz
Whole thread Raw
In response to Re: Why is pq_begintypsend so slow?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, Feb 18, 2024 at 12:09:06PM -0800, Andres Freund wrote:
> On 2024-02-18 17:38:09 +0900, Sutou Kouhei wrote:
>> @@ -1966,7 +1992,7 @@ CopyReadBinaryAttribute(CopyFromState cstate, FmgrInfo *flinfo,
>>      if (fld_size == -1)
>>      {
>>          *isnull = true;
>> -        return ReceiveFunctionCall(flinfo, NULL, typioparam, typmod);
>> +        return ReceiveFunctionCall(fcinfo->flinfo, NULL, attr->typioparam, attr->typmod);
>>
>> Why pre-initialized fcinfo isn't used here?
>
> Because it's a prototype and because I don't think it's a common path.

0008 and 0010 (a bit) are the only patches of the set that touch some
of the areas that would be impacted by the refactoring to use
callbacks in the COPY code, still I don't see anything that could not
be changed in what's updated here, the one-row callback in COPY FROM
being the most touched.  So I don't quite see why each effort could
not happen on their own?

Or Andres, do you think that any improvements you've been proposing in
this area should happen before we consider refactoring the COPY code
to plug in the callbacks?  I'm a bit confused by the situation, TBH.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Erik Wienhold
Date:
Subject: Re: Patch: Add parse_type Function
Next
From: Michael Paquier
Date:
Subject: Re: Add system identifier to backup manifest