Re: Make COPY format extendable: Extract COPY TO format implementations

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Make COPY format extendable: Extract COPY TO format implementations
Дата
Msg-id ZelfYatRdVZN3FbE@paquier.xyz
обсуждение исходный текст
Ответ на Re: Make COPY format extendable: Extract COPY TO format implementations  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Make COPY format extendable: Extract COPY TO format implementations  (Sutou Kouhei <kou@clear-code.com>)
Список pgsql-hackers
On Wed, Mar 06, 2024 at 03:34:04PM +0900, Michael Paquier wrote:
> I am not sure that my schedule is on track to allow that for this
> release, unfortunately, especially with all the other items to review
> and discuss to make this thread feature-complete.  There should be
> a bit more than four weeks until the feature freeze (date not set in
> stone, should be around the 8th of April AoE), but I have less than
> the half due to personal issues.  Perhaps if somebody jumps on this
> thread, that will be possible..

While on it, here are some profiles based on HEAD and v17 with the
previous tests (COPY TO /dev/null, COPY FROM data sent to the void).

COPY FROM, text format with 30 attributes and HEAD:
-   66.53%    16.33%  postgres  postgres            [.] NextCopyFrom
    - 50.20% NextCopyFrom
       - 30.83% NextCopyFromRawFields
          + 16.09% CopyReadLine
            13.72% CopyReadAttributesText
       + 19.11% InputFunctionCallSafe
    + 16.33% _start
COPY FROM, text format with 30 attributes and v17:
-   66.60%    16.10%  postgres  postgres            [.] NextCopyFrom
    - 50.50% NextCopyFrom
       - 30.44% NextCopyFromRawFields
          + 15.71% CopyReadLine
            13.73% CopyReadAttributesText
       + 19.81% InputFunctionCallSafe
    + 16.10% _start

COPY TO, text format with 30 attributes and HEAD:
-   79.55%    15.54%  postgres  postgres            [.] CopyOneRowTo
    - 64.01% CopyOneRowTo
       + 30.01% OutputFunctionCall
       + 11.71% appendBinaryStringInfo
         9.36% CopyAttributeOutText
       + 3.03% CopySendEndOfRow
         1.65% int4out
         1.01% 0xffff83e46be4
         0.93% 0xffff83e46be8
         0.93% memcpy@plt
         0.87% pgstat_progress_update_param
         0.78% enlargeStringInfo
         0.67% 0xffff83e46bb4
         0.66% 0xffff83e46bcc
         0.57% MemoryContextReset
    + 15.54% _start
COPY TO, text format with 30 attributes and v17:
-   79.35%    16.08%  postgres  postgres            [.] CopyOneRowTo
    - 62.27% CopyOneRowTo
       + 28.92% OutputFunctionCall
       + 10.88% appendBinaryStringInfo
         9.54% CopyAttributeOutText
       + 3.03% CopySendEndOfRow
         1.60% int4out
         0.97% pgstat_progress_update_param
         0.95% 0xffff8c46cbe8
         0.89% memcpy@plt
         0.87% 0xffff8c46cbe4
         0.79% enlargeStringInfo
         0.64% 0xffff8c46cbcc
         0.61% 0xffff8c46cbb4
         0.58% MemoryContextReset
    + 16.08% _start

So, in short, and that's not really a surprise, there is no effect
once we use the dispatching with the routines only when a format would
want to plug-in with the APIs, but a custom format would still have a
penalty of a few percents for both if bottlenecked on CPU.
--
Michael

Вложения

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

Предыдущее
От: "Zhijie Hou (Fujitsu)"
Дата:
Сообщение: RE: Synchronizing slots from primary to standby
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum