Re: HIGH IO and Less CPU utilization - Mailing list pgsql-performance

From Justin Pryzby
Subject Re: HIGH IO and Less CPU utilization
Date
Msg-id 20220331064941.GM28503@telsasoft.com
Whole thread Raw
In response to Re: HIGH IO and Less CPU utilization  (Rambabu g <rambabu.g2564@gmail.com>)
Responses Re: HIGH IO and Less CPU utilization  (Rambabu g <rambabu.g2564@gmail.com>)
List pgsql-performance
On Wed, Mar 30, 2022 at 10:17:38AM +0530, Rambabu g wrote:
> Hi Justin,
> 
> Only one query is causing the issue, sharing the def of indexes. Please
> have a look.
> 
> > > There are three indexes defined on the table, each one is around 20 to 25GB
> 
>  tp    | character varying(2000)   | yes    | tp       | extended |
> 
>    852 | 00:09:56.131136 | IO              | DataFileRead  | explain
> analyze select distinct  empno  from emp where sname='test' and tp='EMP
> NAME 1'

The server is doing a scan of the large table.
The tp index matches a lot of rows (13e6) which probably aren't clustered, so
it elects to scan the 500GB table each time.

Looking at this in isolation, maybe it'd be enough to create an index on
tp,empno (and maybe drop the tp index).  CREATE INDEX CONCURRENTLY if you don't
want to disrupt other queries.

But This seems like something that should be solved in a better way though ;
like keeping a table with all the necessary "empno" maintained with "INSERT ON
CONFLICT DO NOTHING".  Or a trigger.



pgsql-performance by date:

Previous
From: Shai Shapira
Date:
Subject: RE: High process memory consumption when running sort
Next
From:
Date:
Subject: Postgresql TPS Bottleneck