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 1qd5Fq-0027h6-RW for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Sep 2023 08:48:18 +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 1qd5Fp-009qZ2-Op for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Sep 2023 08:48:17 +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 1qd5Fp-009qYN-ES for pgsql-hackers@lists.postgresql.org; Mon, 04 Sep 2023 08:48:17 +0000 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qd5Fm-002eOc-9O for pgsql-hackers@postgresql.org; Mon, 04 Sep 2023 08:48:15 +0000 Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7a52a27fe03so496879241.0 for ; Mon, 04 Sep 2023 01:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693817293; x=1694422093; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yaS6/ZCMPQ2DY737i9WbS6PgN39rqizERrZxx7SgW1s=; b=mJ/LsK7mL3RH2Ye0JWfLZwSp4JMI2KOaqazbdW1fnq2XQl4HtriupGR/ORHRAAC+kv SneMRM+sWShmMzqQBL+XFsUaxfiTwZ964QEEiFSBprUe0KPfwrwnZbpcLQriaiA+LiJk DJejh9WaHkGQ9a5LV9im+Pov31QXKJs9Futb2wr9VHx5pPrQ8fDawwGTYz2yIz/35aQX T0pUj90IYpEqn/4DnSjOTepmZgNUPwRGSxhGhEC8eS4Ee2GtDFdF+FFs9Fb9LKIrfM1G sbMcsL/sMMrDIP1QZroc3BpX/GkpSbSNOGToE+2sbijxxfZ/nfntl1Zdu5Uyqd2bxi7r PYfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693817293; x=1694422093; h=content-transfer-encoding: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=yaS6/ZCMPQ2DY737i9WbS6PgN39rqizERrZxx7SgW1s=; b=VnHu+OVL+LYOdtjqo3WiXumpXUY0Vy2Eswv7xBz4HBP+Otpp7EdQCDBBNOwRsHrGa3 kXzxbiGq9ygPTdPsCYdj+lvJObxe63nLrg65vGxmXYhIHZC0+fSeeC6TicpTv7SJTo/L a16cAkavni/bk+IA6WuYeYf0s2AjyKUOL/VNd7vTHCmZZCPHrVwA7HmdJ/CHz57t+b4C 5uaaUgCgLOPvkRmj5BvYkjZhdX3K6972hjep+e5/UJBj8Cw+nk3BpDUogDkuiPWzvYDc 2+I466xnZR9W5ByZ2jg2fB3xYbazm9fjsEblFnMoUKxZ9OzaLS+RFaMzLMXiwtdBA3Jg LqwQ== X-Gm-Message-State: AOJu0Yw6GswbpT/RcJhjQvvsKZCqdLXSoNc9EDZFvGPHh0zW3fJpn5Hu svJjGdrbCkm/voOlIHiTH9+5oLHI7A9iaZGhbbk= X-Google-Smtp-Source: AGHT+IFmkuWA6nexZf39fmawC6AM00ezgOp3/fDKsnX83O9LUH0F6ZGoRQsrodK3L/gChuW9DtIxwG5I19CngF71YEk= X-Received: by 2002:a67:d00b:0:b0:44e:afb0:f45c with SMTP id r11-20020a67d00b000000b0044eafb0f45cmr7111867vsi.28.1693817293159; Mon, 04 Sep 2023 01:48:13 -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> In-Reply-To: <20230902.204634.955758704959569058.t-ishii@sranhm.sra.co.jp> From: jian he Date: Mon, 4 Sep 2023 16:48:02 +0800 Message-ID: Subject: Re: Incremental View Maintenance, take 2 To: Tatsuo Ishii Cc: nagata@sraoss.co.jp, pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Sep 2, 2023 at 7:46=E2=80=AFPM Tatsuo Ishii wr= ote: > > > attached is my refactor. there is some whitespace errors in the > > patches, you need use > > git apply --reject --whitespace=3Dfix > > basedon_v29_matview_c_refactor_update_set_clause.patch > > > > Also you patch cannot use git apply, i finally found out bulk apply > > I have no problem with applying Yugo's v29 patches using git apply, no > white space errors. > thanks. I downloaded the patches from the postgres website, then the problem was solved. other ideas based on v29. src/include/utils/rel.h 680: #define RelationIsIVM(relation) ((relation)->rd_rel->relisivm) I guess it would be better to add some comments to address the usage. Since all peer macros all have some comments. pg_class change, I guess we need bump CATALOG_VERSION_NO? small issue. makeIvmAggColumn and calc_delta need to add an empty return statement? style issue. in gram.y, "incremental" upper case? + CREATE OptNoLog incremental MATERIALIZED VIEW create_mv_target AS SelectStmt opt_with_data I don't know how pgident works, do you need to add some keywords to src/tools/pgindent/typedefs.list to make indentation work? in /* If this is not the last AFTER trigger call, immediately exit. */ Assert (entry->before_trig_count >=3D entry->after_trig_count); if (entry->before_trig_count !=3D entry->after_trig_count) return PointerGetDatum(NULL); before returning NULL, do you also need clean_up_IVM_hash_entry? (I don't know when this case will happen) in /* Replace the modified table with the new delta table and calculate the new view delta*/ replace_rte_with_delta(rte, table, true, queryEnv); refresh_matview_datafill(dest_new, query, queryEnv, tupdesc_new, ""= ); replace_rte_with_delta does not change the argument: table, argument: queryEnv. refresh_matview_datafill just uses the partial argument of the function calc_delta. So I guess, I am confused by the usage of replace_rte_with_delta. also I think it should return void, since you just modify the input argument. Here refresh_matview_datafill is just persisting new delta content to dest_new?