Re: Use get_call_result_type() more widely

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use get_call_result_type() more widely
Date: 2022-12-19 18:43:32
Message-ID: CA+TgmobwNmx1cJOnfB-_BNX0ExonEigDddJemGOwM_1x+KEgNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 13, 2022 at 10:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ted Yu 2022-12-19 18:53:59 Fixing typo in 002_pg_dump.pl
Previous Message Robert Haas 2022-12-19 18:33:46 Re: meson files copyright