From: | Michael Lewis <mlewis(at)entrata(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Adam Sjøgren <asjo(at)koldfront(dot)dk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general <pgsql-general(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Database logins taking longer and longer, showing up as "authentication" in ps(1) |
Date: | 2020-09-30 22:15:46 |
Message-ID: | CAHOFxGr3qAAL1LNJbKAozsgAxXn5xy2C4EFi1DA=jcBbo=eCZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Sep 30, 2020 at 3:41 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 9/30/20 2:30 PM, Adam Sjøgren wrote:
> > Adrian writes:
> >
> >> I don't have an answer. Not even sure if this is relevant to the
> >> problem, but how are the jobs getting into the queue?
> >
> > Plain INSERTs - often a lot at the same time. I inserted 400K jobs to
> > clean up after a bug earlier today, for instance.
> >
> > What were you suspecting?
>
> Honestly a fishing expedition. All the discussion, as far as I could
> remember, had to do with the retrieval part of the process. Just thought
> for completeness it might be useful to flesh out the insertion portion
> of the process. Though it does get one to wondering how the appearance
> of a large number of jobs at once affects the those programs looking for
> new jobs?
>
Is autovacuum/analyze keeping up with the changes to allow the planner to
make prudent choices? With so many updates/deletes, I would hope so but if
still using the 20% or 10% default values for scale_factor, and at times
the table has many millions of rows, perhaps not.
From | Date | Subject | |
---|---|---|---|
Next Message | Glen Eustace | 2020-10-01 00:00:21 | Restoring a database problem |
Previous Message | Adrian Klaver | 2020-09-30 21:41:22 | Re: Database logins taking longer and longer, showing up as "authentication" in ps(1) |