Re: Implementing Incremental View Maintenance

On Wed, 9 Sep 2020 14:22:28 +1200
Thomas Munro <thomas(dot)munro(at)gmail(dot)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(at)sraoss(dot)co(dot)jp>