Re: Proposal for internal Numeric to Uint64 conversion function.

On Tue, May 3, 2022 at 8:04 PM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>
> On 03.05.22 08:50, Amul Sul wrote:
> >> 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).
>
> Ok. I have lost track of what you are trying to achieve with this patch
> set. It's apparently not for performance, and in terms of refactoring
> you end up with more lines of code than before, so that doesn't seem too
> appealing either. So I'm not sure what the end goal is.
>

Well, that is still worth it, IMHO.

Refactoring allows us to place numeric_pg_lsn to the correct file
where it should be. This refactoring, giving a function that converts
numeric to uint64. The same function is used in other routines of
pg_lsn.c which is otherwise using DirectFunctionCall().

Refactoring of numeric_int8() giving a function to convert numeric
to int64 which can be used at the many places without using
DirectFuctionCall(), and that is not the sole reason of it -- we have
a function that converts int64 to numeric but for the opposite
conversion needs to use DirectFuctionCall() which doesn't make
sense.

Along with this refactoring there are different routing calling
functions for the numeric arithmetic operation through
DirectFunctionCall() which isn't necessary since the required
arithmetic functions are already accessible.

The last benefit that is not completely worthless is avoiding
DirectFunctionCall() one less function call stack and one less work
that the system needs to do the same task.

Regards,
Amul