From: | Rui DeSousa <rui(at)crazybean(dot)net> |
---|---|
To: | John Lumby <johnlumby(at)hotmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: admin control over cancelling autovacuum when blocked by a lock |
Date: | 2019-04-30 14:12:11 |
Message-ID: | ACF14079-4541-4300-978C-BEC42339B33F@crazybean.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> On Apr 30, 2019, at 9:27 AM, John Lumby <johnlumby(at)hotmail(dot)com> wrote:
>
> it does do ANALYZE - in this context is that "DDL"?
I would consider that DDL and the application should avoid doing it; otherwise, you end up with blocking issues where both readers and writers are blocked unnecessarily. The application issuing analyze on its own temp tables is fine and non blocking. If you must analyze tables then I would limit which processes have access to those tables to avoid blocking issues.
I would look at your auto vacuum/analyze settings as oppose to the application issuing analyze commands as those are going to be a non blocking option.
From | Date | Subject | |
---|---|---|---|
Next Message | MichaelDBA | 2019-04-30 15:04:40 | Re: admin control over cancelling autovacuum when blocked by a lock |
Previous Message | John Lumby | 2019-04-30 13:27:04 | Re: admin control over cancelling autovacuum when blocked by a lock |