Re: Implementing Incremental View Maintenance - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Implementing Incremental View Maintenance
Date
Msg-id 20190711.113936.1903640014094147259.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Implementing Incremental View Maintenance  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
> I am quite interested to learn how IVM interacts with SERIALIZABLE.

Just for a fun, I have added:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

right after every BEGIN; in incremental_matview.sql in regression test
and it seems it works.

> A couple of superficial review comments:
> 
> +            const char *aggname = get_func_name(aggref->aggfnoid);
> ...
> +            else if (!strcmp(aggname, "sum"))
> 
> I guess you need a more robust way to detect the supported aggregates
> than their name, or I guess some way for aggregates themselves to
> specify that they support this and somehow supply the extra logic.
> Perhaps I just waid what Greg Stark already said, except not as well.

I guess we could use moving aggregate (or partial aggregate?)
functions for this purpose, but then we need to run executor directly
rather using SPI. It needs more codes...

> +                            "WITH t AS ("
> +                            "  SELECT diff.__ivm_count__,
> (diff.__ivm_count__ = mv.__ivm_count__) AS for_dlt, mv.ctid"
> +                            ", %s"
> +                            "  FROM %s AS mv, %s AS diff WHERE (%s) = (%s)"
> +                            "), updt AS ("
> +                            "  UPDATE %s AS mv SET __ivm_count__ =
> mv.__ivm_count__ - t.__ivm_count__"
> +                            ", %s "
> +                            "  FROM t WHERE mv.ctid = t.ctid AND NOT for_dlt"
> +                            ") DELETE FROM %s AS mv USING t WHERE
> mv.ctid = t.ctid AND for_dlt;",
> 
> I fully understand that this is POC code, but I am curious about one
> thing.  These queries that are executed by apply_delta() would need to
> be converted to C, or at least used reusable plans, right?  Hmm,
> creating and dropping temporary tables every time is a clue that the
> ultimate form of this should be tuplestores and C code, I think,
> right?

Yes, we could reuse the temp tables and plans.

> Then our unofficial automatic CI system[1] will run these tests every
> day, which sometimes finds problems.
> 
> [1] cfbot.cputube.org

I appreciate that you provide the system.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Copy data to DSA area
Next
From: Thomas Munro
Date:
Subject: Re: Index Skip Scan