On 6/9/15 9:52 AM, Kevin Grittner wrote:
Yeah, I think we want to preserve the ability of count() to have a simple state, and implement dependent aggregates as discussed in the other thread -- where (as I understood it) having sum(x), count(x), and avg(x) in a query would avoid the row-by-row work for sum(x) and count(x), and just invoke a final function to extract those values from the transition state of the avg(x) aggregate. I see incremental maintenance of materialized views taking advantage of the same sort of behavior, only maintaining the state for avg(x) during incremental maintenance and*at the end* pulling the values for sum(x) and count(x) out of that.
Last I checked, Oracle forbade things like avg() in matviews. Since it's trivial to calculate avg() by hand, I don't see that as a big deal. It'd be nice to not require that, but it'd be MUCH nicer to have any kind of incremental matview update.
Just trying to keep things in perspective. :) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers