Re: confusing / inefficient "need_transcoding" handling in copy
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Sutou Kouhei <kou@clear-code.com>, Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <ishii@sraoss.co.jp>
Date: 2024-02-06T04:49:38Z
Lists: pgsql-hackers
On Mon, Feb 05, 2024 at 06:05:04PM -0800, Andres Freund wrote: > I don't really understand why we need to validate anything during COPY TO? > Which is good, because it turns out that we don't actually validate anything, > as pg_server_to_any() returns without doing anything if the encoding matches: > > if (encoding == DatabaseEncoding->encoding || > encoding == PG_SQL_ASCII) > return unconstify(char *, s); /* assume data is valid */ > > This means that the strlen() we do in the call do pg_server_to_any(), which on > its own takes 14.25% of the cycles, computes something that will never be > used. Indeed, that's wasting cycles for nothing when the client and server encoding match. > Unsurprisingly, only doing transcoding when encodings differ yields a sizable > improvement, about 18% for [2]. > > I haven't yet dug into the code history. One guess is that this should only > have been set this way for COPY FROM. Looking the git history, this looks like an oversight of c61a2f58418e that has added the condition on pg_database_encoding_max_length(), no? Adding Tom and Ishii-san, even if this comes from 2005. -- Michael
Commits
-
Add some tests for encoding conversion in COPY TO/FROM
- 3ad8b840ce8b 18.0 landed
-
Improve COPY TO performance when server and client encodings match
- b619852086ed 17.0 landed