From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: NUMERIC private methods? |
Date: | 2014-12-16 08:23:39 |
Message-ID: | 548FEC0B.40309@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/16/2014 08:34 AM, David Fetter wrote:
> Folks,
>
> While noodling with some weighted statistics
> <https://github.com/davidfetter/weighted_stats>, I noticed I was
> having to jump through a lot of hoops because of all the private
> methods in numeric.c, especially NumericVar. Would there be some
> major objection to exposing NumericVar as an opaque blob?
Hmm. You'd want to make add_var, mul_var etc. non-static?
Looking at the weighed_stats code, this probably illustrates the hoops
you had to jump through:
> /* sqrt((n/(n-1)) * ((s0*s2 - s1*s1)/(s0*s0)) */
>
> result
> = DirectFunctionCall1(
> numeric_sqrt,
> DirectFunctionCall2(
> numeric_mul,
> DirectFunctionCall2(
> numeric_div,
> n_prime,
> DirectFunctionCall2(
> numeric_sub,
> n_prime,
> /*
> * This rather convoluted way to compute the value
> * 1 gives us a result which should have at least
> * as big a decimal scale as s_2 does, which should
> * guarantee that our result is as precise as the
> * input...
> */
> DirectFunctionCall2(
> numeric_add,
> DirectFunctionCall2(
> numeric_sub,
> state->s_2,
> state->s_2
> ),
> make_numeric(1)
> )
> )
> ),
> DirectFunctionCall2(
> numeric_div,
> DirectFunctionCall2(
> numeric_sub,
> DirectFunctionCall2(
> numeric_mul,
> state->s_0,
> state->s_2
> ),
> DirectFunctionCall2(
> numeric_mul,
> state->s_1,
> state->s_1
> )
> ),
> DirectFunctionCall2(
> numeric_mul,
> state->s_0,
> state->s_0
> )
> )
> )
> );
As a start, it would help a lot to #define a few helper macros like:
#define ADD(a, b) DirectFunctionCall2(numeric_add, a, b)
#define MUL(a, b) DirectFunctionCall2(numeric_mul, a, b)
in your extension. That would already make that a lot shorter.
You might also be worrying about performance, though. The above snippet
was from the aggregate's final function, which isn't performance
critical, but you have some numeric operations in the transition
function too. I wonder how big the impact really is, though.
init_var_from_num and make_result look quite cheap, but certainly not free.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Borodin Vladimir | 2014-12-16 08:24:22 | Re: Streaming replication and WAL archive interactions |
Previous Message | Craig Ringer | 2014-12-16 07:55:39 | Re: Commitfest problems |