From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why does [auto-]vacuum delay not report a wait event? |
Date: | 2020-03-20 11:54:31 |
Message-ID: | CABUevEwzsKq=QF1tG5smLW68Ye3eANRAm3GS40vMO+cSbLG48w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 20, 2020 at 12:32 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Mar 20, 2020 at 4:15 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > Hi,
> >
> > I was looking at [1], wanting to suggest a query to monitor what
> > autovacuum is mostly waiting on. Partially to figure out whether it's
> > mostly autovacuum cost limiting.
> >
> > But uh, unfortunately the vacuum delay code just sleeps without setting
> > a wait event:
> >
> > void
> > vacuum_delay_point(void)
> > {
> > ...
> > /* Nap if appropriate */
> > if (msec > 0)
> > {
> > if (msec > VacuumCostDelay * 4)
> > msec = VacuumCostDelay * 4;
> >
> > pg_usleep((long) (msec * 1000));
> >
> >
> > Seems like it should instead use a new wait event in the PG_WAIT_TIMEOUT
> > class?
> >
>
> +1. I think it will be quite helpful.
Definite +1. There should be a wait event, and identifying this
particular case is certainly interesting enough that it should have
it's own.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Pengzhou Tang | 2020-03-20 11:57:02 | Re: Parallel grouping sets |
Previous Message | Amit Kapila | 2020-03-20 11:31:57 | Re: Why does [auto-]vacuum delay not report a wait event? |