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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sutou Kouhei <kou(at)clear-code(dot)com>
Cc: andres(at)anarazel(dot)de, sawada(dot)mshk(at)gmail(dot)com, zhjwpku(at)gmail(dot)com, andrew(at)dunslane(dot)net, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Date: 2024-03-07 06:32:01
Message-ID: ZelfYatRdVZN3FbE@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)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(at)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-03-07 06:49:18 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Zhijie Hou (Fujitsu) 2024-03-07 06:30:09 RE: Synchronizing slots from primary to standby