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.
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
Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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
