Date: Mon, 4 Mar 2024 11:53:44 +0900
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: jian he <jian.universality@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Incremental View Maintenance, take 2
Message-Id: <20240304115344.01b363b0d02738a2b49cf9bd@sraoss.co.jp>
In-Reply-To: <CACJufxEoCCJE1vntJp1SWjen8vBUa3vZLgL=swPwar4zim976g@mail.gmail.com>
References: <20230601235909.0e1572c27e59112f9d0cbe86@sraoss.co.jp>
	<20230601034703.9e4f81f5d92ae6e3949b84d2@sraoss.co.jp>
	<CACJufxE8Kct5=c1KKi_JgP09WApCk0Myk6=a5xo05_J_mB7hRQ@mail.gmail.com>
	<20230628170604.505955118ac2f91abd554f13@sraoss.co.jp>
	<CACJufxEA-V+0Fa3Q6xQrFwG6wLs4DsX7E4exdfA=rO-70svmBw@mail.gmail.com>
	<CACJufxHZkF_e4JvcXCfaYkOSs0p6-S2SFQk1+iOHdDL6kvngKg@mail.gmail.com>
	<CACJufxHtG9h_1V2pr+Hx9amWE9fW0z3dcW9t8yMiBgiSsEjBQA@mail.gmail.com>
	<CACJufxHVrgBM1FhM7=df9Cky_uPJ8o3wTjT0iKJWDgmbYPTYqw@mail.gmail.com>
	<CACJufxHJQ-Tvxyj1Fy5O3ULXn912bnF1pHfCmLTR72Qcy2_-iQ@mail.gmail.com>
	<CACJufxHMG9Pmc=W8QMHvk_RwUBABDZNh9HgO4JSQtp1+JUPTJg@mail.gmail.com>
	<CACJufxF-HGe9zLaGaSryeYVq9abz2FyKKtdgghNWktkjnFXOJQ@mail.gmail.com>
	<20230828024908.2667bcde8d2963256375bd6c@sraoss.co.jp>
	<20230828115252.c1b018605b9a0756a30c3382@sraoss.co.jp>
	<20230828160530.adde1e20f257d7d345989163@sraoss.co.jp>
	<CACJufxEoCCJE1vntJp1SWjen8vBUa3vZLgL=swPwar4zim976g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20240304115344.01b363b0d02738a2b49cf9bd%40sraoss.co.jp>
Precedence: bulk

On Fri, 1 Sep 2023 15:42:17 +0800
jian he <jian.universality@gmail.com> wrote:

I apologize for this late reply. 

> I added a new function  append_update_set_caluse, and deleted
> functions: {append_set_clause_for_count, append_set_clause_for_sum,
> append_set_clause_for_avg, append_set_clause_for_minmax}
> 
> I guess this way is more extensible/generic than yours.

Do you mean that consolidating such functions to a general function
make easier to support a new aggregate function in future? I'm not
convinced completely yet it because your suggestion seems that every
functions' logic are just put into a new function, but providing a
common interface might make a sense a bit.

By the way, when you attach files other than updated patches that
can be applied to master branch, using ".patch" or ".diff" as the
file extension help to avoid  to confuse cfbot (for example, like
basedon_v29_matview_c_refactor_update_set_clause.patch.txt).

> src/backend/commands/matview.c
> 2268: /* For tuple deletion */
> maybe "/* For tuple deletion and update*/" is more accurate?

This "deletion" means deletion of tuple from the view rather 
than DELETE statement, so I think this is ok. 

> Since the apply delta query is quite complex, I feel like adding some
> "if debug then print out the final querybuf.data end if" would be a
> good idea.

Agreed, it would be helpful for debugging. I think it would be good
to add a debug macro that works if DEBUG_IVM is defined rather than
adding GUC like debug_print_..., how about it?

> we add hidden columns somewhere, also to avoid corner cases, so maybe
> somewhere we should assert total attribute number is sane.

The number of hidden columns to be added depends on the view definition
query, so I wonder the Assert condition would be a bit complex. Could
you explain what are you assume about like for example? 

Regards,
Yugo Nagata

-- 
Yugo NAGATA <nagata@sraoss.co.jp>