From: | Wells Oliver <wells(dot)oliver(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Mat view sometimes taking 10x the time to refresh concurrently |
Date: | 2021-05-27 16:38:13 |
Message-ID: | CAOC+FBWrPdQtzQUvTiOKhYJ-jxsHowg3afqQ_cBvTHtyNThAFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Wells Oliver <wells(dot)oliver(at)gmail(dot)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
>
--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-05-27 16:43:56 | Re: now() and statement_timestamp() |
Previous Message | Vijaykumar Jain | 2021-05-27 16:38:10 | Re: Mat view sometimes taking 10x the time to refresh concurrently |