On Tue, Nov 16, 2021 at 5:43 PM Robert Creager <robe...@spectralogic.com> wrote: > One CPU is pegged, the data has been sent over STDIN, so Postgres is not > waiting for more, there are no other queries running using this select:
So PostgreSQL is eating 100% CPU, with no value shown in wait_event_type, and small numbers of system calls are counted. In that case, is there an interesting user stack that jumps out with a profiler during the slowdown (or the kernel version, stack())? sudo dtrace -n 'profile-99 /arg0/ { @[ustack()] = count(); } tick-10s { exit(0); }'