From: | Paul Draper <paulddraper(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | kgrittn(at)gmail(dot)com, thomas(dot)munro(at)gmail(dot)com |
Subject: | Re: Implementing Incremental View Maintenance |
Date: | 2019-09-15 17:52:22 |
Message-ID: | CAApx4VQJHtiXXoPaEsr51awFE8GZr8m+HB_q5YV7R27bT4p82w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
As I understand it, the current patch performs immediate IVM using AFTER
STATEMENT trigger transition tables.
However, multiple tables can be modified *before* AFTER STATEMENT triggers
are fired.
CREATE TABLE example1 (a int);
CREATE TABLE example2 (a int);
CREATE INCREMENTAL MATERIALIZED VIEW mv AS
SELECT example1.a, example2.a
FROM example1 JOIN example2 ON a;
WITH
insert1 AS (INSERT INTO example1 VALUES (1)),
insert2 AS (INSERT INTO example2 VALUES (1))
SELECT NULL;
Changes to example1 are visible in an AFTER STATEMENT trigger on example2,
and vice versa. Would this not result in the (1, 1) tuple being
"double-counted"?
IVM needs to either:
(1) Evaluate deltas "serially' (e.g. EACH ROW triggers)
(2) Have simultaneous access to multiple deltas:
delta_mv = example1 x delta_example2 + example2 x delta_example1 -
delta_example1 x delta_example2
This latter method is the "logged" approach that has been discussed for
deferred evaluation.
tl;dr It seems that AFTER STATEMENT triggers required a deferred-like
implementation anyway.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-09-15 20:02:51 | Re: (Re)building index using itself or another index of the same table |
Previous Message | Kuntal Ghosh | 2019-09-15 17:26:48 | Re: POC: Cleaning up orphaned files using undo logs |