Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZ309-00G3XX-Pz for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jul 2024 06:39:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sZ307-001pXT-Vb for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jul 2024 06:39:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZ307-001pXJ-L4 for pgsql-hackers@lists.postgresql.org; Wed, 31 Jul 2024 06:39:55 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZ304-002KYX-Rs for pgsql-hackers@postgresql.org; Wed, 31 Jul 2024 06:39:54 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f032cb782dso59071051fa.3 for ; Tue, 30 Jul 2024 23:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722407991; x=1723012791; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R3HC0AINRZdfXNqkGSNXfuwTJhAtK8gTggepNEugcyY=; b=MUKFUDgaU3rqE2IPfpLdwJK+CojS6UbsxY2u0p4FwiDMCWtgsdO9VpDGcpXdbi7ICu y6QngqfGUjBFJ0KJRj+EgJxYlR/vu6J86g3ooR+iY5ZsogSggEBJomPruorJup1uCyU1 YMO69AaDBDIdPjB8sQQcp/I7u4+jph0xfG3imLRV+F2mvtGQNk0N51CtRWpX4YDjU/rx DI0367aJMFrkdir/jyFX8dzGp1oLFCtd62PNAT1D72FKqTvFdKt3+RP1Dt3KnmoQ7oan DtkQsleRfnToVwuGHFXLRonStS79+863q7leq6NA8GxD7t0bOCBU73AEHC3myyjNDnhE NdlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722407991; x=1723012791; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R3HC0AINRZdfXNqkGSNXfuwTJhAtK8gTggepNEugcyY=; b=AZ27XK5Txep+RjjBggvpsQjdZ1xMy82RppB9Ya94ExSIUFoEoqIBlx7CGBiLsfwOM6 bHS2GXDXXsje8MhcRMlle3weiHA5Dtxijk6t0FS5Eyrrd21vcZhRvIqZGcVh8RcX9ldm aIwxuKPUc5gspEo3pJk0+YRyNuamGsQKkrK/pa4jV1QRSjMXqz8upDlb8uWRQs5ULOuC X8QdVppoupRBAT7neEQ3RNCm6/48duvD01qY5gLd8uy+qReXn/WqnlIDDTKrkmZwNfua 7iJ+O7SvM8VG1ognG8NREHG8HL54iTMMUAQHviWFvW77AQ2WNshrvVPG792TXbtW5qXl l92w== X-Forwarded-Encrypted: i=1; AJvYcCVQOsdPg1mWA9mUekRyEMwlhqdO2FZGk0Ncj/w3CDg7hPhdUVwp1fVpptMPve+y/atggHnAHS4Vd049pyLYITj1VBJL2zwFuiJuj5Uo X-Gm-Message-State: AOJu0YxtKr6S58qaPn0hkW7GR2r83921lBXIg8iW/XRdj1+pH2uWlZe9 ugPKfZfc1CP1Z2wTmXfMCpt4DOk0io1jEv8kXhJ7D+5H19zdMQ91Jk2d7lewn2JOgGCLPbc3dyB yZZirULBe6qJJv3A1/njdB6mCbPA= X-Google-Smtp-Source: AGHT+IHmMKzLsorrZcwpPJyF+u1bufwQjgRM8dF7BIC9XPEz1Ihk8mXEEhJAP/75HyhogkwLxXkVH6xJXtEMP10xc60= X-Received: by 2002:a2e:9646:0:b0:2ef:2cbc:9072 with SMTP id 38308e7fff4ca-2f12ee6ab81mr83745401fa.49.1722407990339; Tue, 30 Jul 2024 23:39:50 -0700 (PDT) MIME-Version: 1.0 References: <20230828115252.c1b018605b9a0756a30c3382@sraoss.co.jp> <20230828160530.adde1e20f257d7d345989163@sraoss.co.jp> <20230902.204634.955758704959569058.t-ishii@sranhm.sra.co.jp> <20240123162327.c2803162619dd7634cca0b6c@sraoss.co.jp> <20240304115846.2275fb44fd904e8789d43590@sraoss.co.jp> <20240329234700.73ff2e28c9248d29f8fa6a66@sraoss.co.jp> <20240331225931.712683cecb26862b73b2b822@sraoss.co.jp> <20240702170311.1ddb417759a48ff12c555b92@sranhm.sraoss.co.jp.sranhm> <20240711132357.fe3f78c184cfa99159208178@sranhm.sraoss.co.jp> In-Reply-To: From: Kirill Reshke Date: Wed, 31 Jul 2024 11:39:37 +0500 Message-ID: Subject: Re: Incremental View Maintenance, take 2 To: Yugo NAGATA Cc: Peter Smith , jian he , Tatsuo Ishii , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 30 Jul 2024 at 03:32, Kirill Reshke wrote: > > On Sat, 27 Jul 2024 at 13:26, Kirill Reshke wrote: > > > > Hi! > > Cloudberry DB (Greenplum fork) uses IMMV feature for AQUMV (auto query > > use matview) feature, so i got interested in how it is implemented. > > > > On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote: > > > > > > I updated the patch to bump up the version numbers in psql and pg_dump codes > > > from 17 to 18. > > > > Few suggestions: > > > > 1) `Add-relisivm-column-to-pg_class-system-catalog` commit message > > should be fixed, there is "isimmv" in the last line. > > 2) I dont get why `Add-Incremental-View-Maintenance-support.patch` > > goes after 0005 & 0004. Shoulndt we first implement feature server > > side, only when client (psql & pg_dump) side? > > 3) Can we provide regression tests for each function separately? Test > > for main feature in main patch, test for DISTINCT support in > > v34-0007-Add-DISTINCT-support-for-IVM.patch etc? This way the patchset > > will be easier to review, and can be committed separelety. > > 4) v34-0006-Add-Incremental-View-Maintenance-support.patch no longer > > applies due to 4b74ebf726d444ba820830cad986a1f92f724649. After > > resolving issues manually, it does not compile, because > > 4b74ebf726d444ba820830cad986a1f92f724649 also removes > > save_userid/save_sec_context fields from ExecCreateTableAs. > > > > > if (RelationIsIVM(matviewRel) && stmt->skipData) > > Now this function accepts skipData param. > > > > 5) For DISTINCT support patch uses hidden __ivm* columns. Is this > > design discussed anywhere? I wonder if this is a necessity (only > > solution) or if there are alternatives. > > 6) > > What are the caveats of supporting some simple cases for aggregation > > funcs like in example? > > ``` > > regress=# CREATE INCREMENTAL MATERIALIZED VIEW mv_ivm_2 AS SELECT > > sum(j) + sum(i) from mv_base_a; > > ERROR: expression containing an aggregate in it is not supported on > > incrementally maintainable materialized view > > ``` > > I can see some difficulties with division CREATE IMMV .... AS SELECT > > 1/sum(i) from mv_base_a; (sum(i) == 0 case), but adding & > > multiplication should be ok, aren't they? > > > > > > Overall, patchset looks mature, however it is far from being > > committable due to lack of testing/feedback/discussion. There is only > > one way to fix this... Test and discuss it! > > > > > > [1] https://github.com/cloudberrydb/cloudberrydb > > Hi! Small update: I tried to run a regression test and all > IMMV-related tests failed on my vm. Maybe I'm doing something wrong, I > will try to investigate. > > Another suggestion: support for \d and \d+ commands in psql. With v34 > patchset applied, psql does not show anything IMMV-related in \d mode. > > ``` > reshke=# \d m1 > Materialized view "public.m1" > Column | Type | Collation | Nullable | Default > --------+---------+-----------+----------+--------- > i | integer | | | > Distributed by: (i) > > > reshke=# \d+ m1 > Materialized view "public.m1" > Column | Type | Collation | Nullable | Default | Storage | > Compression | Stats target | Description > --------+---------+-----------+----------+---------+---------+-------------+--------------+------------- > i | integer | | | | plain | > | | > View definition: > SELECT t1.i > FROM t1; > Distributed by: (i) > Access method: heap > > ``` > > Output should be 'Incrementally materialized view "public.m1"' IMO. And one more thing, noticed today while playing with patchset: I believe non-terminal incremental should be OptIncremental Im talking about this: ``` incremental: INCREMENTAL { $$ = true; } | /*EMPTY*/ { $$ = false; } ; ```