Hi Greg, On Wed, 3 Apr 2019 17:41:36 -0400 Greg Stark <st...@mit.edu> wrote:
> 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. Thank you for your suggestion! I submitted the latest patch just now supporting some aggregate functions, but this supports only sum and count, and lacking a kind of generalization. However, I would like to refine this to support more general aggregate functions. I think your suggestions is helpful for me to do this. Thank you! Best regards, Yugo Nagata -- Yugo Nagata <nag...@sraoss.co.jp>
