On Tue, Jul 14, 2020 at 9:27 PM Vishwa Kalyankar <vishwakalyankar8@xxxxxxxxx> wrote: > Function Scan on kseb_geometry_trace_with_barrier_partition (cost=0.25..10.25 rows=1000 width=169) (actual time=11626.548..11626.568 rows=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.448 rows=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
