Re: Why is pq_begintypsend so slow?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Why is pq_begintypsend so slow?
Дата
Msg-id ZdKGYI8x2EsHwaPn@paquier.xyz
обсуждение исходный текст
Ответ на Re: Why is pq_begintypsend so slow?  (Andres Freund <andres@anarazel.de>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Erik Wienhold
Дата:
Сообщение: Re: Patch: Add parse_type Function
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add system identifier to backup manifest