Re: Incremental View Maintenance, take 2 (design considerations)

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "zmlpostgres(at)gmail(dot)com" <zmlpostgres(at)gmail(dot)com>
Subject: Re: Incremental View Maintenance, take 2 (design considerations)
Date: 2026-06-30 15:04:01
Message-ID: 20260701000401.5764e8c72dd007a9b139309a@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 29 May 2026 23:14:17 +0900
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:

> There are still various design trade-offs to consider, so comments and discussion
> on the overall direction would be greatly appreciated.

While I'm still working on those design changes and scope reduction,
I've attached an updated patch to fix the broken test in the previous
patch set.

I'll send another patch set reflecting those changes once it's ready.

Regards,
Yugo Nagata

> On Sun, 22 Feb 2026 23:41:17 +0900
> Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> > On Mon, 16 Feb 2026 21:43:09 +0000
> > Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
> >
> > Thank you for looking over and updating the patches!
> > I’m planning an overhaul of the patch set, but I really appreciate your time
> > and effort in getting them up to date.
> >
> > > Sorry,
> > > the previous line missed the removal of the function declared but not used.
> > >
> > > Regards,
> > > Alexandre
> > >
> > > On Mon, Feb 16, 2026 at 4:07 PM Alexandre Felipe <
> > > o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
> > >
> > > > There was a warning on my initial rebase, so I fixed that.
> > > >
> > > > I also changed the bitmap set to a list, I don't think we need O(1) lookup
> > > > here as suggested by Zhang [1] on patch 6.
> > > >
> > > > Yugo,
> > > > I think there is an issue in
> > > > src/backend/commands/matview.c, IVM_immediate_maintenance, line 1688, when
> > > > apply_delta fails, and PG_RE_THROW is called, wouldn't we have to cleanup?
> > > > As in line 1699 onwards?
> >
> > Do you mean calling clean_up_IVM_hash_entry() as part of the cleanup?
> > I would need to look into this more carefully, but my understanding is that i
> > might be handled by AtAbort_IVM() in that situation.
> >
> > Regards,
> > Yugo Nagata
> >
> > > >
> > > >
> > > >
> > > > Regards,
> > > > Alexandre
> > > >
> > > > On Thu, Feb 12, 2026 at 6:08 PM Alexandre Felipe <
> > > > o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
> > > >
> > > >> Sorry for creating a new thread for this.
> > > >> I don't have the original email.
> > > >>
> > > >> This is my attempt on rebasing
> > > >> https://commitfest.postgresql.org/patch/4337/
> > > >>
> > > >> Regards,
> > > >> Alexandre
> > > >>
> > > >
> >
> >
> > --
> > Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
> >
> >
>
>
> --
> Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
v38-0011-Add-documentations-about-Incremental-View-Mainte.patch text/x-diff 24.7 KB
v38-0010-Add-regression-tests-for-Incremental-View-Mainte.patch text/x-diff 155.6 KB
v38-0009-Add-support-for-min-max-aggregates-for-IVM.patch text/x-diff 26.5 KB
v38-0008-Add-aggregates-support-in-IVM.patch text/x-diff 38.2 KB
v38-0007-Add-DISTINCT-support-for-IVM.patch text/x-diff 24.6 KB
v38-0006-Add-Incremental-View-Maintenance-support.patch text/x-diff 91.2 KB
v38-0005-Add-Incremental-View-Maintenance-support-to-psql.patch text/x-diff 5.7 KB
v38-0004-Add-Incremental-View-Maintenance-support-to-pg_d.patch text/x-diff 4.2 KB
v38-0003-Allow-to-prolong-life-span-of-transition-tables-.patch text/x-diff 6.0 KB
v38-0002-Add-relisivm-column-to-pg_class-system-catalog.patch text/x-diff 6.0 KB
v38-0001-Add-a-syntax-to-create-Incrementally-Maintainabl.patch text/x-diff 5.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-06-30 15:18:30 Re: statatt_build_stavalues->LOCAL_FCINFO wrong number
Previous Message Robert Haas 2026-06-30 14:52:07 Re: pg_plan_advice: FOREIGN_JOIN advice generated for a single-relation foreign scan is not round-trip safe