From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Mat view sometimes taking 10x the time to refresh concurrently
In-reply-to: 
 <CAOC+FBVa10yEcxQ4heZeXA3n9Foa3O=GUWrY-ZgkrCsBrfC8tQ@mail.gmail.com>
References: 
 <CAOC+FBVa10yEcxQ4heZeXA3n9Foa3O=GUWrY-ZgkrCsBrfC8tQ@mail.gmail.com>
Comments: In-reply-to Wells Oliver <wells.oliver@gmail.com>
	message dated "Thu, 27 May 2021 09:15:12 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1785390.1622133411.1@sss.pgh.pa.us>
Date: Thu, 27 May 2021 12:36:51 -0400
Message-ID: <1785391.1622133411@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1785391.1622133411%40sss.pgh.pa.us>
Precedence: bulk

Wells Oliver <wells.oliver@gmail.com> writes:
> Hey, we have a mat view that normally takes ~18m to re-materialize
> concurrently, which we do daily. Maybe once a week, it takes ~180m to
> refresh, and we're at a loss as to why.
> We are running backs during the same general time window, where we do
> backup the schema where this mat view is located, could this be an issue?
> We have not noticed any lock errors in the backup or log, though.
> Any tips on tracing this down would be appreciated.

My own mindset would be to wonder if a different/worse plan is being
chosen.  You could investigate that perhaps by running an EXPLAIN
on the matview's query just before each refresh, to see if it changes.

Checking pg_locks for ungranted locks while the REFRESH is running
would be good to do too, although I'd think that a backup vs. a
concurrent refresh shouldn't have that sort of problem.

It seems possible also that you're just maxing out the machine's
I/O capacity between these two tasks.

			regards, tom lane