Re: Use get_call_result_type() more widely - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Use get_call_result_type() more widely
Date
Msg-id 2334526.1670946171@sss.pgh.pa.us
Whole thread Raw
In response to Use get_call_result_type() more widely  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Use get_call_result_type() more widely
Re: Use get_call_result_type() more widely
List pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> A review comment in another thread [1] by Michael Paquier about the
> usage of get_call_result_type() instead of explicit building of
> TupleDesc made me think about using it more widely. Actually, the
> get_call_result_type() looks at the function definitions to figure the
> column names and build the required TupleDesc, usage of which avoids
> duplication of the column names between pg_proc.dat/function
> definitions and source code. Also, it saves a good number of LOC ~415
> [2] and the size of all the object files put together gets reduced by
> ~4MB, which means, the postgres binary becomes leaner by ~4MB [3].

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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: Bharath Rupireddy
Date:
Subject: Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures