Date: Mon, 2 Dec 2019 15:42:08 +0900
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: alvherre@2ndquadrant.com, pgsql-hackers@postgresql.org,
 hoshiai@sraoss.co.jp, thomas.munro@gmail.com, kgrittn@gmail.com
Subject: Re: Implementing Incremental View Maintenance
Message-Id: <20191202154208.b613271eff61bc34b570d009@sraoss.co.jp>
In-Reply-To: <20191202.103636.874135993509990496.t-ishii@sraoss.co.jp>
References: <20191128171052.ee3948fad09eb9337fcbbfc9@sraoss.co.jp>
	<20191128140333.GA25947@alvherre.pgsql>
	<20191129173328.e5a0e9f81e369a3769c4fd0c@sraoss.co.jp>
	<20191202.103636.874135993509990496.t-ishii@sraoss.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 02 Dec 2019 10:36:36 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

> >> One thing pending in this development line is how to catalogue aggregate
> >> functions that can be used in incrementally-maintainable views.
> >> I saw a brief mention somewhere that the devels knew it needed to be
> >> done, but I don't see in the thread that they got around to doing it.
> >> Did you guys have any thoughts on how it can be represented in catalogs?
> >> It seems sine-qua-non ...
> > 
> > Yes, this is a pending issue. Currently, supported aggregate functions are
> > identified their name, that is, we support aggregate functions named "count",
> > "sum", "avg", "min", or "max". As mentioned before, this is not robust
> > because there might be user-defined aggregates with these names although all
> > built-in aggregates can be used in IVM.
> > 
> > In our implementation, the new aggregate values are calculated using "+" and
> > "-" operations for sum and count, "/" for agv, and ">=" / "<=" for min/max. 
> > Therefore, if there is a user-defined aggregate on a user-defined type which
> > doesn't support these operators, errors will raise. Obviously, this is a
> > problem.  Even if these operators are defined, the semantics of user-defined
> > aggregate functions might not match with the way of maintaining views, and
> > resultant might be incorrect.
> > 
> > I think there are at least three options to prevent these problems.
> > 
> > In the first option, we support only built-in aggregates which we know able
> > to handle correctly. Supported aggregates can be identified using their OIDs.
> > User-defined aggregates are not supported. I think this is the simplest and
> > easiest way.
> 
> I think this is enough for the first cut of IVM. So +1.

If there is no objection, I will add the check of aggregate functions
by this way. Thanks.

Regards,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>