Thread: Same query taking less time in low configuration machine

> On Jul 14, 2020, at 5:27 AM, Vishwa Kalyankar <vishwakalyankar8@gmail.com> wrote:
>
> Hi,
>
> I have two machines - one with 8GB RAM & 4core CPU and the other with 64GB Ram & 24 core CPU.  Both machines have the
sameDB (Postgres 12 + Postgis 2.5.3).  Same query is taking less time in low end machine whereas more time in high end
machine. Any thoughts on where to look?  I have tuned the db in both machines according to
https://pgtune.leopard.in.ua/#/ 
>
>
> Below I am pasting the output of query explain in both the machines.
>
>  -bash-4.2$ psql -p 5434
> psql (12.3)
> Type "help" for help.
>
> postgres=# \c IPDS_KSEB;
> You are now connected to database "IPDS_KSEB" as user "postgres".
> IPDS_KSEB=# explain analyze select * from
kseb_geometry_trace_with_barrier_partition(5,'kottarakara_version',437,'htline',2); 
>                                                                        QUERY PLAN
>
---------------------------------------------------------------------------------------------------------------------------------------------------------
>  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) 
>  Planning Time: 0.212 ms
>  Execution Time: 11628.590 ms
>
>
> -bash-4.2$ psql -p 5422
> psql (12.3)
> Type "help" for help.
>
> postgres=# \c IPDS_KSEB;
> You are now connected to database "IPDS_KSEB" as user "postgres".
> IPDS_KSEB=# explain analyze select * from
kseb_geometry_trace_with_barrier_partition(5,'kottarakara_version',437,'htline',2); 
>                                                                        QUERY PLAN
>
---------------------------------------------------------------------------------------------------------------------------------------------------------
>  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) 
>  Planning Time: 0.219 ms
>  Execution Time: 22352.219 ms
> (3 rows)
>

Hi Vishwa,
Is it possible that your data is in the cache on the low end machine but not on the high end machine? There’s both the
Postgrescache and the OS disk cache to consider. You can see what’s in the Postgres cache with an extension like
pg_buffercache.I don’t know of a way to see what’s in the OS cache; maybe others do. 

Cheers
Philip

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

On Thu, 16 Jul 2020 at 09:50, Thomas Munro <thomas.munro@gmail.com> wrote:
> 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.

It might also be good to look at size of the tables and indexes that
are looked at within the function. If the smaller end machine was
loaded with data via pg_restore form a pg_dump taken from the larger
machine then the indexes might be in much better shape and the heap
may have less bloat.  Of course, that's just speculation. We've not
seen what the function does yet.

Vishwa, it would be good if you could follow the guide here:
https://wiki.postgresql.org/wiki/Slow_Query_Questions , in particular:

"Post the definitions of all tables and indexes referenced in the
query. If the query touches views or custom functions, we'll need
those definitions as well. Run psql command "\d table" with the
tables/views/indices referenced in the problem query."

David