Re: Use get_call_result_type() more widely

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Use get_call_result_type() more widely
Дата
Msg-id CA+TgmobwNmx1cJOnfB-_BNX0ExonEigDddJemGOwM_1x+KEgNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Use get_call_result_type() more widely  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Use get_call_result_type() more widely  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Tue, Dec 13, 2022 at 10:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Saving code is nice, but I'd assume the result is slower, because
> get_call_result_type has to do a pretty substantial amount of work
> to get the data to construct the tupdesc from.  Have you tried to
> quantify how much overhead this'd add?  Which of these functions
> can we safely consider to be non-performance-critical?

Here's a modest proposal: let's do nothing about this. There's no
evidence of a real problem here, so we're going to be trying to judge
the performance benefits against the code size savings without any
real data indicating that either one is an issue. I bet we could
convert all of these to one style or the other and it would make very
little real world difference, but deciding which ones to change and in
which direction will take up time and energy that could otherwise be
spent on more worthwhile projects, and could possibly complicate
back-patching, too.

Basically, I think this is nit-picking. Let's just accept that both
styles have some advantages and leave it up to patch authors to pick
one that they prefer.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: meson files copyright
Следующее
От: Ted Yu
Дата:
Сообщение: Fixing typo in 002_pg_dump.pl