Date: Wed, 23 May 2018 07:03:18 -0700 (MST)
From: pavan95 <pavan.postgresdba@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1527084198212-0.post@n3.nabble.com>
In-Reply-To: <20180523134322.GK30060@telsasoft.com>
References: <1526883356469-0.post@n3.nabble.com>
 <1526917693149-0.post@n3.nabble.com> <1526985179479-0.post@n3.nabble.com>
 <20180522103906.GF30060@telsasoft.com> <1526986304012-0.post@n3.nabble.com>
 <20180522182307.GA9330@telsasoft.com>
 <CACh9nsb_voDr57vRrwvhFsCGuT1SzRMWvbQz1wnU5miK1sdWbQ@mail.gmail.com>
 <1527058866609-0.post@n3.nabble.com> <20180523134322.GK30060@telsasoft.com>
Subject: Re: Help me in reducing the CPU cost for the high cost query below,
 as it is hitting production seriously!!
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Justin,

>How big is the table ?  And curract_state_isfinal_app_idx ? 
>Have these been reindexed (or pg_repacked) recently? 

The size of the table 'tms_workflow_history' is 7600Kb(which is pretty
small). Yes those indexes were dropped and recreated. 

>It looks like you resolved the bad estimate on the users table? 
Yeah, even I think the same.

Please find the explain plan which got increased again vastly. Is this
because of the increase in rows?

Link :  https://explain.depesz.com/s/Ifr <http://>  

The above is the explain plan taken from production server. And this is the
main plan to tune.

Please let me know the where I'm going wrong. Thank you in Advance.!!

Regards,
Pavan


--
Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html