| From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
|---|---|
| To: | 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-14 01:41:51 |
| Message-ID: | 52D495DF.7010806@archidevsys.co.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
Cheers,
Gavin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-01-14 01:48:57 | Re: Linux kernel impact on PostgreSQL performance |
| Previous Message | Josh Berkus | 2014-01-14 01:40:22 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |