Re: confusing / inefficient "need_transcoding" handling in copy

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: confusing / inefficient "need_transcoding" handling in copy
Дата
Msg-id ZcG6YuQ15j3H0whd@paquier.xyz
обсуждение исходный текст
Ответ на confusing / inefficient "need_transcoding" handling in copy  (Andres Freund <andres@anarazel.de>)
Ответы Re: confusing / inefficient "need_transcoding" handling in copy  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

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

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: 2024-02-08 release announcement draft
Следующее
От: jian he
Дата:
Сообщение: Re: remaining sql/json patches