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

From: Jim Nasby <jim(at)nasby(dot)net>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Florian Pflug <fgp(at)phlo(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, 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-15 07:19:57
Message-ID: 52D6369D.3080604@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/13/14, 7:41 PM, Gavin Flower wrote:
> On 14/01/14 14:29, Tom Lane wrote:
> [...]
>> (2) the float and numeric variants should be implemented under nondefault names (I'm thinking FAST_SUM(), but bikeshed away). People who need extra speed and don't mind the slightly different results can alter their queries to use these variants. One reason I'm thinking this is that whatever we do to ameliorate the semantic issues is going to slow down the forward transition function --- to no benefit unless the aggregate is being used as a window function in a moving window. So I'm less than convinced that we *should* implement any of these designs in the default aggregates, even if we get to the point where we arguably *could* do it with little risk of functional differences. regards, tom lane
> How SUM_FAST() instead, then it will more likely to be close to SUM() in an index?

+1. That's what I do in cases like this.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-01-15 07:36:08 Re: Capturing EXPLAIN ANALYZE for a query without discarding the normal result set
Previous Message Erik Rijkers 2014-01-15 07:10:27 Re: nested hstore patch - FailedAssertion("!(value->array.nelems == 1)