Date: Thu, 31 Jan 2019 21:38:58 +0900
From: Yugo Nagata <nagata@sraoss.co.jp>
To: =?UTF-8?B?Tmd1eeG7hW4gVHLhuqduIFF14buRYw==?= Vinh <ntquocvinh@gmail.com>
Cc: Adam Brusselback <adambrusselback@gmail.com>, denty <denty@qqdd.eu>, Pg
 Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Implementing Incremental View Maintenance
Message-Id: <20190131213858.210c22579d192e722d32ac2d@sraoss.co.jp>
In-Reply-To: 
 <CAAU9oxvByms37Cdo2RW+8CD1WtVJxNS4sapvqU68EPL=ULjrLQ@mail.gmail.com>
References: <20181227215726.4d166b4874f8983a641123f5@sraoss.co.jp>
	<1546252875009-0.post@n3.nabble.com>
	<CAMjNa7cogDibpuGF=MDdaJGxKmnnz7pcxwp2ZwFFE-WjxUoNsA@mail.gmail.com>
	<CAAU9oxvByms37Cdo2RW+8CD1WtVJxNS4sapvqU68EPL=ULjrLQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 1 Jan 2019 14:46:25 +0700
Nguy=E1=BB=85n Tr=E1=BA=A7n Qu=E1=BB=91c Vinh <ntquocvinh@gmail.com> wrot=
e:

> We have some result on incremental update for MVs. We generate triggers=
 on
> C to do the incremental maintenance. We posted the code to github about=
 1
> year ago, but unfortunately i posted a not-right ctrigger.h header. The
> mistake was exposed to me when a person could not compile the generated
> triggers and reported to me. And now i re-posted with the right ctrigge=
r.h
> file.
>=20
> You can find the codes of the generator here:
> https://github.com/ntqvinh/PgMvIncrementalUpdate/commits/master. You ca=
n
> find how did we do here:
> https://link.springer.com/article/10.1134/S0361768816050066. The paper =
is
> about generating of codes in pl/pgsql. Anyway i see it is useful for
> reading the codes. I don't know if i can share the paper or not so that=
 i
> don't publish anywhere else. The text about how to generate triggers in=
 C
> was published with open-access but unfortunately, it is in Vietnamese.
>=20
> We are happy if the codes are useful for someone.

I have read your paper. It is interesting and great so that the algorithm
is described concretely.

After reading this, I have a few questions about your implementation.
Although I may be able to understand by reading your paper and code caref=
ully,
I would appreciate it if you could answer these.

- It is said there are many limitations on the view definition query.
  How does this work when the query is not supported?

- Is it possible to support materialized views that have DISTINCT,
  OUTER JOIN, or sub-query in your approach?

- It is said that AVG is splitted to SUM and COUNT. Are these new additio=
nal
  columns in MV visible for users?

- Does this can handle the race condition discussed in [1], that is,
  if concurrent transactions update different two tables in the join
  view definition, is MV updated sucessfully?

[1] https://www.postgresql.org/message-id/flat/1368561126.64093.YahooMail=
Neo%40web162904.mail.bf1.yahoo.com

Regards,
--=20
Yugo Nagata <nagata@sraoss.co.jp>