public inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: 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
Date: Mon, 4 Mar 2024 11:53:44 +0900
Message-ID: <20240304115344.01b363b0d02738a2b49cf9bd@sraoss.co.jp> (raw)
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>
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>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nagata@sraoss.co.jp, jian.universality@gmail.com
Subject: Re: Incremental View Maintenance, take 2
In-Reply-To: <20240304115344.01b363b0d02738a2b49cf9bd@sraoss.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox