Thanks, Tom. I will dig into those ideas. I do think the I/O capacity might ultimately be a big factor.
On Thu, May 27, 2021 at 9:36 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Wells Oliver <wells.oliver@xxxxxxxxx> 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
Wells Oliver
wells.oliver@xxxxxxxxx
wells.oliver@xxxxxxxxx
