Re: Optimizing Node Files Support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimizing Node Files Support
Дата
Msg-id 2962750.1673018283@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimizing Node Files Support  (Ranier Vilela <ranier.vf@gmail.com>)
Ответы Re: Optimizing Node Files Support  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
Список pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em qua., 4 de jan. de 2023 às 19:39, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>> Yeah.  The way that I'd been thinking of optimizing the copy functions
>> was more or less as attached: continue to write all the COPY_SCALAR_FIELD
>> macro calls, but just make them expand to no-ops after an initial memcpy
>> of the whole node.

> I think this option is worse.
> By disabling these macros, you lose their use in other areas.

What other areas?  They're local to copyfuncs.c.

The bigger picture here is that as long as we have any manually-maintained
node copy functions, it seems best to adhere to the existing convention
of explicitly listing each and every field in them.  I'm far more
concerned about errors-of-omission than I am about incremental performance
gains (which still haven't been demonstrated to exist, anyway).

> v3 attached.

I think you're wasting people's time if you don't provide some
performance measurements showing that this is worth doing from
a speed standpoint.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Resolve iso-8859-1 type to relevant type instead of text type while bulk update using values
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert