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
