On Mon, Jan 4, 2021 at 9:05 PM Luc Vlaming <l...@swarm64.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.
