Re: Proposal for internal Numeric to Uint64 conversion function.

On Mon, May 2, 2022 at 8:23 PM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)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