Re: [PATCH] Negative Transition Aggregate Functions (WIP)

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date: 2014-01-16 11:02:19
Message-ID: CAApHDvpOzMs-uQ6nCWf3ey0UNXw9FCUeM_rkVMDVdhNUPSZYmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 16, 2014 at 9:45 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:

> I'm currently thinking the best way forward is to get a basic patch
> without any NUMERIC stuff committed, and to revisit this after that's done.
>
>
Attached is a version to that effect. The number of inverse transition
functions is down to 8 from 36.

I managed to keep avg(interval) in there as it's all integer based division.
sum for all int types remain, plus sum for interval and cash. count(exp)
and count(*) also naturally remain.

sum(bigint) became a bit weird as it uses numeric types internally, so I
had to keep the do_numeric_discard() function to support it. Previously
this function did NaNCount-- if it was removing a NaN numeric, but since I
got rid of the NaNCounter as it was no longer required I just decided to
throw an error if we encounter a numeric with NaN. I thought this was ok as
the only place the function is being called the numeric value being passed
is built from a bigint which obviously can't be NaN. It may be better to
just get rid of do_numeric_discard() and stick the sub_var(&(state->sumX),
newval, &(state->sumX)); into int8_avg_accum_inv(). I don't have a
preference as to which as I think there's reasons for both ways. Perhaps
even the name int8_avg_accum_inv() is misleading as we never use it for
avg(bigint). Anyway, I'll leave it as is for now as I just can't decide
which way is better.

Florian, I've not had a chance to look at your updated v2.2 patch yet
sorry. I'll try and get some time tomorrow evening.

Regards

David Rowley

> best regards,
> Florian Pflug
>
>

Attachment Content-Type Size
inverse_transition_functions_v2.3.patch.gz application/x-gzip 18.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-01-16 12:19:46 Re: [RFC] overflow checks optimized away
Previous Message Marko Tiikkaja 2014-01-16 10:49:44 Re: Display oprcode and its volatility in \do+