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 1sYYv1-00CLTu-A3 for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Jul 2024 22:32:39 +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 1sYYuz-003lQz-Q4 for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Jul 2024 22:32:37 +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 1sYYuz-003lQr-GM for pgsql-hackers@lists.postgresql.org; Mon, 29 Jul 2024 22:32:37 +0000 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sYYuw-0026qJ-GZ for pgsql-hackers@postgresql.org; Mon, 29 Jul 2024 22:32:35 +0000 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2f035ae0ff1so36537761fa.0 for ; Mon, 29 Jul 2024 15:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722292352; x=1722897152; 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=f3q82va/SjqhUO6H1zoj1CGBfT+lIk6nl/rlLQojv/w=; b=Oke8VggVekqenYV92xZ6z09ZqIM6OrNegtDNOkzqsydcD+/t1DDn8pUbMOhpbEkktR HjKFewcb6dCG1Awl3ORENiE/z10cFIqbINpbRrWy+e04Bv4Nd6tiaxAuU34r+yS6E/fi 05S3a/+dVtSLllki5vi2gsn6tjg8QCmORyQmTpEArP3zFkeh8OQgb3nZpXJSxPgAQiFv AxqUdQQgj8o+3VY0EK17Y9IQ4BiuCczwZV2Zcn56vFJGfdkPCcDedoUhf/0YNoY/M8+u oI1WKzjpO++N4Nzhl6VX6yCWatNQN9Scg5XZTcDUv8iUbcLuP3Sn2OiL66zwR+73EJeg 5GRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722292352; x=1722897152; 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=f3q82va/SjqhUO6H1zoj1CGBfT+lIk6nl/rlLQojv/w=; b=kSDvQ8LEJonnLbZSpk0hWrnovAcubqcGcRPpR2b2D6xh5RjdI4e6nBajsyqOL5YJxC ev00ItFwTLGyme4MMvXtdpRYEKGB+W7eKs+JLsd0SJiFtDHSlYTtnJ+bjiex0NnWEDk7 lVfzOFDM3+gtP5krF9Kjfc4Mx+xpjEarWmI+XuXVp6L4bMNYSkSbUnVUnCtl7u0QROIN ostZlyG/JThLBkFRoZ8870LJXW+mU+7mcQFveOmVEu0Fr7y+/9DKf9yKqNqrIlAQdMqx 7SFDt6u3Jh62lwd27VKGSFBfUOBaWhJY4sfDLfqrIl9si0xhEKmoJJmMKC+lcA8fxDZv 324g== X-Forwarded-Encrypted: i=1; AJvYcCX0f7DDPJGVjg35pi4S1LJSSpYw/5OuDKDBec7CgfEwRvT/JX8FTP6wBu8J/V9BQbEffipKGjvzJVuXTuPKRUyiQ02MYwGUceHk649m X-Gm-Message-State: AOJu0YwxvZIC2BHmKImhh8iTymboRnJ9A/ROXfBFe4ytAtU3weI7fueA DLOsKRZMYDXyw2aYiXXA9WrREA5bYXkHgY0UQtUWl4F6uDNOAWPczUnTYagM1oiXH7YxvXqk0Ue EXa820EDRhPXu+fehgmqDNAOLSMk= X-Google-Smtp-Source: AGHT+IF4JfFqYqPx2A1RNECDXHODcrsUtoGtL7PqDEzJm/10xKcxPaxENmbBa8FLEq3tMbHdpf2LLYtm2u+EUuLd1D0= X-Received: by 2002:a2e:1f11:0:b0:2ef:23e9:a3ca with SMTP id 38308e7fff4ca-2f147945f94mr237681fa.18.1722292352126; Mon, 29 Jul 2024 15:32:32 -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: Tue, 30 Jul 2024 03:32:19 +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 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.