Date: Mon, 2 Dec 2019 13:48:40 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: Tatsuo Ishii <ishii@sraoss.co.jp>, pgsql-hackers@postgresql.org,
	hoshiai@sraoss.co.jp, thomas.munro@gmail.com, kgrittn@gmail.com
Subject: Re: Implementing Incremental View Maintenance
Message-ID: <20191202164840.GA8271@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191202154208.b613271eff61bc34b570d009@sraoss.co.jp>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2019-Dec-02, Yugo Nagata wrote:

> 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 ...

> > > 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.

The way I imagine things is that there's (one or more) new column in
pg_aggregate that links to the operator(s) (or function(s)?) that
support incremental update of the MV for that aggregate function.  Is
that what you're proposing?

All that query-construction business in apply_delta() looks quite
suspicious.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services