Re: [PATCH] Negative Transition Aggregate Functions (WIP)
От
Tom Lane
Тема
Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Дата
Msg-id
25399.1389662981@sss.pgh.pa.us
Ответ на
Re: [PATCH] Negative Transition Aggregate Functions (WIP) (Florian Pflug)
Список
Дерево обсуждения
[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 по дате отправления