On Tue, Jul 14, 2020 at 9:27 PM Vishwa Kalyankar
<vishwakalyankar8@gmail.com> wrote:
> Function Scan on kseb_geometry_trace_with_barrier_partition (cost=0.25..10.25 rows=1000 width=169) (actual
time=11626.548..11626.568rows=254 loops=1)
> Function Scan on kseb_geometry_trace_with_barrier_partition (cost=0.25..10.25 rows=1000 width=169) (actual
time=22304.425..22304.448rows=254 loops=1)
I have no idea what that function does, but perhaps it runs more
queries, and you can't see the plans for those here. If you set up
auto_explain[1], and turn on auto_explain.log_nested_statements, then
you'll be able to see the query plans for the internal stuff happening
in that function.
I'd look at EXPLAIN (BUFFERS) or auto_explain.log_buffers to get more
information on cache hits and misses. I'd look for settings
differences with EXPLAIN (SETTINGS) to see if there's anything
accidentally set differently (maybe JIT or paralelism or something
like that). I'd look at pg_stat_activity repeatedly while it runs to
see what the processes are doing, especially the wait_event column.
I'd also look at the CPU and I/O on the systems with operating system
tools like iostat, htop, perf to try to find the difference.
[1] https://www.postgresql.org/docs/current/auto-explain.html