public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kirill Reshke <[email protected]>
To: Yugo NAGATA <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: jian he <[email protected]>
Cc: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Subject: Re: Incremental View Maintenance, take 2
Date: Tue, 20 Aug 2024 12:06:24 +0500
Message-ID: <CALdSSPg1mPiZRXjFEsz3h_5Jue0rq0w9BJzBrcVtwz5J29d_3w@mail.gmail.com> (raw)
In-Reply-To: <CALdSSPiBBBCHxVtg+X6OdBkJPGYOvLf1hST4MgBgRKZh0Xddyw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CACJufxEoCCJE1vntJp1SWjen8vBUa3vZLgL=swPwar4zim976g@mail.gmail.com>
<[email protected]>
<CACJufxFjankFQDNppOfqCTpY=zW4Q0+2WCmKjT95kggiT978Lw@mail.gmail.com>
<CAHut+PsDpBTxZ7bLhko7_E-C7khMhoNJcriNQ_p_gWjADn01vg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<20240702170311.1ddb417759a48ff12c555b92@sranhm.sraoss.co.jp.sranhm>
<[email protected]>
<CALdSSPhj1H1NS7QiYkSQNCksPCwjtLcyt3==evgkBX1SrKyVdQ@mail.gmail.com>
<CALdSSPip9ruUoQMmsD_hQ0xY72qB=_jB-ayHeUWUH-dd0MB60A@mail.gmail.com>
<[email protected]>
<CALdSSPiBBBCHxVtg+X6OdBkJPGYOvLf1hST4MgBgRKZh0Xddyw@mail.gmail.com>
On Tue, 20 Aug 2024 at 02:14, Kirill Reshke <[email protected]> wrote:
>
>
> == Major suggestions.
>
> 1) At first glance, working with this IVM/IMMV infrastructure feels
> really unintuitive about what servers actually do for query execution.
> I do think It will be much better for user experience to add more
> EXPLAIN about IVM work done inside IVM triggers. This way it is much
> clearer which part is working slow, so which index should be created,
> etc.
>
> 2) The kernel code for IVM lacks possibility to be extended for
> further IVM optimizations. The one example is foreign key optimization
> described here[1]. I'm not saying we should implement this within this
> patchset, but we surely should pave the way for this. I don't have any
> good suggestions for how to do this though.
>
> 3) I don't really think SQL design is good. CREATE [INCREMENTAL] M.V.
> is too ad-hoc. I would prefer CREATE M.V. with (maintain_incr=true).
> (reloption name is just an example).
> This way we can change regular M.V. to IVM and vice versa via ALTER
> M.V. SET *reloptions* - a type of syntax that is already present in
> PostgreSQL core.
>
One little follow-up here. Why do we do prepstate visibility the way
it is done? Can we instead export the snapshot in BEFORE trigger, save
it somewhere and use it after?
--
Best regards,
Kirill Reshke
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Incremental View Maintenance, take 2
In-Reply-To: <CALdSSPg1mPiZRXjFEsz3h_5Jue0rq0w9BJzBrcVtwz5J29d_3w@mail.gmail.com>
* 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