huge shared_blocks_hit one select but manually run very fast - Mailing list pgsql-performance

From James Pang
Subject huge shared_blocks_hit one select but manually run very fast
Date
Msg-id CAHgTRff_1mTsU-QSaDBY5k9+D-i9sV0aQeRY9ShffV=6b7jOWQ@mail.gmail.com
Whole thread Raw
Responses Re: huge shared_blocks_hit one select but manually run very fast
List pgsql-performance
Hi, 
   we have a simple select .... from table where ... (that mache the index) , table has 80million rows.  when many application sessions run the query and at the same time some other sessions doing insert into ... this table. from pg_stat_statements, shared_blks_hit show 31652 / per call.   we see very high cpu almost 100% cpu during application workload test, and high LWLock BufferMapping waiting for these querys.  But manually run the sql show only 2148 shared_blks_hit/ per call.  this is a simple sql, from pg_profile we did see it use same index scan as manually running.  What could be possible reason leading so big difference with shared_blks_hit ?  
 PGv14.8 

Thanks,

James

pgsql-performance by date:

Previous
From: Jon Zeppieri
Date:
Subject: Re: Why a bitmap scan in this case?
Next
From: David Mullineux
Date:
Subject: Re: huge shared_blocks_hit one select but manually run very fast