[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)
From:       Michael Lewis <mlewis () entrata ! com>
Date:       2020-09-30 22:15:46
Message-ID: CAHOFxGr3qAAL1LNJbKAozsgAxXn5xy2C4EFi1DA=jcBbo=eCZw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Sep 30, 2020 at 3:41 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

> On 9/30/20 2:30 PM, Adam Sj=C3=B8gren 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.

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr">On Wed, Sep 30, 2020 at 3:41 PM Adrian Klaver &lt;<a \
href="mailto:adrian.klaver@aklaver.com">adrian.klaver@aklaver.com</a>&gt; \
wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On 9/30/20 2:30 PM, Adam Sjøgren wrote:<br> &gt; \
Adrian writes:<br> &gt; <br>
&gt;&gt; I don&#39;t have an answer. Not even sure if this is relevant to the<br>
&gt;&gt; problem, but how are the jobs getting into the queue?<br>
&gt; <br>
&gt; Plain INSERTs - often a lot at the same time. I inserted 400K jobs to<br>
&gt; clean up after a bug earlier today, for instance.<br>
&gt; <br>
&gt; What were you suspecting?<br>
<br>
Honestly a fishing expedition. All the discussion, as far as I could <br>
remember, had to do with the retrieval part of the process. Just thought <br>
for completeness it might be useful to flesh out the insertion portion <br>
of the process. Though it does get one to wondering how the appearance <br>
of a large number of jobs at once affects the those programs looking for <br>
new jobs?<br></blockquote><div><br></div><div>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.  \
</div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]