Re: Consecutive Query Executions with Increasing Execution Time

Hi everyone!

Thanks a ton for this brilliant discussion here!
It turned out that Nicolas was correct! I found that the CPU was broken and
not spinning at all.
With consecutive parallel query execution, the CPU temperature hits 100C
almost immediately after 1 or 2 iterations.
So the processor starts throttling way below baseline clk frequency to
something like 1.2G or even 1G.

I waited until the new Fan came to report back, and now this weird behavior
went away.

Thanks,
Shijia

On Wed, Dec 18, 2019 at 7:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Tue, 2019-12-17 at 11:11 -0500, Jeff Janes wrote:
> >> If it is doing a seq scan (I don't know if it is) they intentionally
> use a
> >> small ring buffer to, so they evict their own recently used blocks,
> rather
> >> than evicting other people's blocks. So these blocks won't build up in
> >> shared_buffers very rapidly just on the basis of repeated seq scans.
>
> > Sure, but according to the execution plans it is doing a Parallel Index
> Only Scan.
>
> Nonetheless, the presented test case consists of repeatedly doing
> the same query, in a fresh session each time. If there's not other
> activity then this should reach some sort of steady state. The
> table is apparently fairly large, so I don't find it surprising
> that the steady state fails to be 100% cached.
>
> regards, tom lane
>