On Sun, 31 Mar 2019 at 23:22, Yugo Nagata <nag...@sraoss.co.jp> wrote: > > Firstly, this will handle simple definition views which includes only > selection, projection, and join. Standard aggregations (count, sum, avg, > min, max) are not planned to be implemented in the first patch, but these > are commonly used in materialized views, so I'll implement them later on.
It's fine to not have all the features from day 1 of course. But I just picked up this comment and the followup talking about splitting AVG into SUM and COUNT and I had a comment. When you do look at tackling aggregates I don't think you should restrict yourself to these specific standard aggregations. We have all the necessary abstractions to handle all aggregations that are feasible, see https://www.postgresql.org/docs/devel/xaggr.html#XAGGR-MOVING-AGGREGATES What you need to do -- I think -- is store the "moving aggregate state" before the final function. Then whenever a row is inserted or deleted or updated (or whenever another column is updated which causes the value to row to enter or leave the aggregation) apply either aggtransfn or aggminvtransfn to the state. I'm not sure if you want to apply the final function on every update or only lazily either may be better in some usage.
