Re: Implementing Incremental View Maintenance - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: Implementing Incremental View Maintenance
Date
Msg-id 20200909144924.45bde284ec8b2a7b29250d7c@sraoss.co.jp
Whole thread Raw
In response to Re: Implementing Incremental View Maintenance  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Wed, 9 Sep 2020 14:22:28 +1200
Thomas Munro <thomas.munro@gmail.com> wrote:

> > Therefore, usual update semantics (tuple locks and EvalPlanQual) and UPSERT
> > can be used for optimization for some classes of view, but we don't have any
> > other better idea than using table lock for views joining tables.  We would
> > appreciate it if you could suggest better solution.
> 
> I have nothing, I'm just reading starter papers and trying to learn a
> bit more about the concepts at this stage.  I was thinking of
> reviewing some of the more mechanical parts of the patch set, though,
> like perhaps the transition table lifetime management, since I have
> worked on that area before.

Thank you for your interrest. It would be greatly appreciated if you
could review the patch.

> > > (Newer papers describe locking schemes that avoid even aggregate-row
> > > level conflicts, by taking advantage of the associativity and
> > > commutativity of aggregates like SUM and COUNT.  You can allow N
> > > writers to update the aggregate concurrently, and if any transaction
> > > has to roll back it subtracts what it added, not necessarily restoring
> > > the original value, so that nobody conflicts with anyone else, or
> > > something like that...  Contemplating an MVCC, no-rollbacks version of
> > > that sort of thing leads to ideas like, I dunno, update chains
> > > containing differential update trees to be compacted later... egad!)
> >
> > I am interested in papers you mentioned!  Are they literatures in context of
> > incremental view maintenance?
> 
> Yeah.  I was skim-reading some parts of [1] including section 2.5.1
> "Concurrency Control", which opens with some comments about
> aggregates, locking and pointers to "V-locking" [2] for high
> concurrency aggregates.  There is also a pointer to G. Graefe and M.
> J. Zwilling, "Transaction support for indexed views," which I haven't
> located; apparently indexed views are Graefe's name for MVs, and
> apparently this paper has a section on MVCC systems which sounds
> interesting for us.
> 
> [1] https://dsf.berkeley.edu/cs286/papers/mv-fntdb2012.pdf
> [2] http://pages.cs.wisc.edu/~gangluo/latch.pdf

Thanks for your information!  I will also check references
regarding with IVM and concurrency control.

Regards,
Yugo Nagata

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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Inconsistent Japanese name order in v13 contributors list