Re: Query Rewrite for Materialized Views (Postgres Extension)

From: Dent John <denty(at)QQdd(dot)eu>
To: Nico Williams <nico(at)cryptonector(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: Query Rewrite for Materialized Views (Postgres Extension)
Date: 2018-06-26 21:53:15
Message-ID: 965FB899-AD3C-4292-99CA-075B7E52E83A@QQdd.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nico,

By the way, I do agree with your point about MERGE — if we can factor MV updates in that fashion, it will certainly save.

I didn’t reply immediately because your point caught me off guard:

> […] If you look at my
> sketch for how to do it, you'll notice that many of the sorts of queries
> that one would choose to materialize... are not really amenable to this
> treatment […]

I’d rather presumed that there would be many examples of DML on base relations that could trigger a direct (incremental) update to the MV. I had presumed it, but not actually done any research.

So I did a bit of a trawl. There’s actually quite a lot of academic research out there, including [1] and [2]. [2] references a bunch of methods for incremental MV refresh, and ties them into a graph query context. I’m not sure if the graph query context itself is relevant for Postgres, but it’s certainly interesting and perhaps suggests that incremental refresh of at least some RECURSIVE MVs may not be entirely impossible. I also found [3], which is /very/ dated, but it strongly supports that MVs are a performant path to executing certain types of query.

So I definitely agree with you in the general case, but it seems there is scope to provide an incremental MV refresh capability that is broadly useful.

Almost certainly, any initial implementation would quickly fall back to a “full refresh”. But the refresh planner’s capability develops, I wonder if it could not embody an intelligent strategy that might even recognise common recursive patterns such as the transitive closure you mention, and refresh on an incremental basis — that would be really quite a cool capability to have.

denty.

[1] http://www.dbnet.ece.ntua.gr/pubs/uploads/TR-1998-14.ps <http://www.dbnet.ece.ntua.gr/pubs/uploads/TR-1998-14.ps>
[2] https://arxiv.org/pdf/1806.07344.pdf <https://arxiv.org/pdf/1806.07344.pdf>
[3] https://www.cs.indiana.edu/pub/techreports/TR280.pdf <https://www.cs.indiana.edu/pub/techreports/TR280.pdf>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2018-06-26 22:02:39 Re: Name of main process differs between servers (postmaster vs postgres)
Previous Message Jonathan Lemig 2018-06-26 21:51:32 Name of main process differs between servers (postmaster vs postgres)