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

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Дата
Msg-id
25399.1389662981@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
[PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Greg Stark <stark@mit.edu>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Robert Haas <robertmhaas@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Florian Pflug <fgp@phlo.org>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Florian Pflug <fgp@phlo.org>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Florian Pflug <fgp@phlo.org>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) David Rowley <dgrowleyml@gmail.com>
Re: [PATCH] Negative Transition Aggregate Functions (WIP) Nicolas Barbier <nicolas.barbier@gmail.com>
Florian Pflug  writes:
> I think it'd be worthwile to get this into 9.4, if that's still an option,
> even if we only support COUNT.

My thought is

(1) we can certainly implement inverse transitions for COUNT() and the
integer variants of SUM(), and that alone would be a killer feature for
some people.

(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


В списке pgsql-hackers по дате отправления
От: Josh Berkus
Дата:
Сообщение: Re: plpgsql.consistent_into
От: Josh Berkus
Дата:
FAQ