Re: Help me in reducing the CPU cost for the high cost query below,as it is hitting production seriously!! - Mailing list pgsql-performance

From Pavan Teja
Subject Re: Help me in reducing the CPU cost for the high cost query below,as it is hitting production seriously!!
Date
Msg-id CACh9nsb_voDr57vRrwvhFsCGuT1SzRMWvbQz1wnU5miK1sdWbQ@mail.gmail.com
Whole thread Raw
In response to Re: Help me in reducing the CPU cost for the high cost query below,as it is hitting production seriously!!  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Help me in reducing the CPU cost for the high cost query below,as it is hitting production seriously!!
List pgsql-performance
Thanks a lot!  I will have a look

On Tue, May 22, 2018, 11:53 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
On Tue, May 22, 2018 at 03:51:44AM -0700, pavan95 wrote:
> Please find the output of explain(analyze,buffers) for the whole query in
> the below link.

> Seq Scan on res_users users (cost=750.92..1,836.69 rows=249 width=15) (actual time=3.962..17.544 rows=67 loops=1)

Not sure but would you try creating an index on:
res_users.res_employee_id

> Seq Scan on res_users user1 (cost=0.00..58.03 rows=1,303 width=15) (actual time=0.002..0.002 rows=1 loops=1)

Also the planner's estimate for table:res_users is off by 1300x..so you should
probably vacuum analyze it then recheck.  I don't think we know what version
postgres you have, but last week's patch releases include a fix which may be
relevant (reltuples including dead tuples).

Also I don't know the definition of this table or its indices:
tms_workflow_history

..but it looks like an additional or modified index or maybe clustering the
table on existing index might help (active? is_final_approver?)
Or maybe this should be 3 separate indices rather than composite index?
Perhaps some of those could be BRIN indices, depending on postgres version

Justin

pgsql-performance by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Help me in reducing the CPU cost for the high cost query below,as it is hitting production seriously!!
Next
From: Sand Stone
Date:
Subject: Re: dsa_allocate() faliure