On Mon, May 2, 2022 at 8:23 PM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > > On 22.04.22 14:26, Amul Sul wrote: > > Yes, I think we can do cleanup to some extent. Attaching the > > following patches that first intend to remove DirectFunctionCall as > > much as possible: > > Do you have any data that supports removing DirectionFunctionCall() > invocations? I suppose some performance benefit could be expected, or > what do you have in mind? >
Not really, the suggestion to avoid DirectionFunctionCall() is from Tom. For a trial, I have called the money(numeric) function 10M times to see the difference with and without patch but there is not much. (I don't have any knowledge of micro profiling/benchmarking). Next I have looked in the profile stack for numeric_mul_opt_error() execution which is called by the numeric_cash() via DirectionFunctionCall() to numeric_mul() see this: 0.99% postgres postgres [.] numeric_mul_opt_error | --- numeric_mul_opt_error | |--94.86%-- numeric_mul | DirectFunctionCall2Coll | numeric_cash | ExecInterpExpr | ExecScan | ExecSeqScan | standard_ExecutorRun | ExecutorRun | PortalRunSelect | PortalRun | exec_simple_query | PostgresMain | ServerLoop | PostmasterMain | main | __libc_start_main | --5.14%-- DirectFunctionCall2Coll numeric_cash ExecInterpExpr ExecScan ExecSeqScan standard_ExecutorRun ExecutorRun PortalRunSelect PortalRun exec_simple_query PostgresMain ServerLoop PostmasterMain main __libc_start_main AFAIC, DirectionFunctionCall() involves some cost and the question is why not to call numeric_mul_opt_error() directly, if that is possible. Regards, Amul