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

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Дата
Msg-id 52D6369D.3080604@nasby.net
обсуждение исходный текст
Ответ на Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Список 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
bikeshedaway). People who need extra speed and don't mind the slightly different results can alter their queries to use
thesevariants. One reason I'm thinking this is that whatever we do to ameliorate the semantic issues is going to slow
downthe forward transition function --- to no benefit unless the aggregate is being used as a window function in a
movingwindow. So I'm less than convinced that we *should* implement any of these designs in the default aggregates,
evenif 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@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Erik Rijkers"
Дата:
Сообщение: Re: nested hstore patch - FailedAssertion("!(value->array.nelems == 1)
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Capturing EXPLAIN ANALYZE for a query without discarding the normal result set