Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW

On Mon, Jan 4, 2021 at 9:05 PM Luc Vlaming <luc(at)swarm64(dot)com> wrote:
> The new status of this patch is: Ready for Committer

I think the comments above this might as well be removed, because they
aren't very convincing:

+-- Allow parallel planning of the underlying query for refresh materialized
+-- view. We can be ensured that parallelism will be picked because of the
+-- enforcement done at the beginning of the test.
+refresh materialized view parallel_mat_view;

If you just leave the REFRESH command, at least it'll be exercised,
and I know you have a separate CF entry to add EXPLAIN support for
REFRESH. So I'd just rip these weasel words out and then in a later
commit you can add the EXPLAIN there where it's obviously missing.

While reading some back history, I saw that commit e9baa5e9 introduced
parallelism for CREATE M V, but REFRESH was ripped out of the original
patch by Robert, who said:

> The problem with a case like REFRESH MATERIALIZED VIEW is that there's
> nothing to prevent something that gets run in the course of the query
> from trying to access the view (and the heavyweight lock won't prevent
> that, due to group locking). That's probably a stupid thing to do,
> but it can't be allowed to break the world. The other cases are safe
> from that particular problem because the table doesn't exist yet.

Hmmm.