Message-ID: <5508130E.8030202@2ndquadrant.com>
Date: Tue, 17 Mar 2015 12:42:06 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Organization: 2ndQuadrant
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: vjoshi@zetainteractive.com, Jim Nasby <Jim.Nasby@bluetreble.com>,
 Scott Marlowe <scott.marlowe@gmail.com>,
 Varadharajan Mukundan <srinathsmn@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Performance issues
References: <84a6fe4be04c3ef0a714851977860ac8@mail.gmail.com>
	<CACKkDGF=Qx_fUje5meLAMFWMJ-c7AUZ9V4GDtBDpr3zO3VKwpA@mail.gmail.com>
	<160b8780d89add7f23c4eb9c3debb99d@mail.gmail.com>
	<CACKkDGETLNUON-bLM0gCo_r-+ts3Q29aQwmargv1Usi=PgQvVg@mail.gmail.com>
	<CANwLwatODrcwDgO+JXG-L=jJJQTucvUrur01E-y_tE_PT8i7kQ@mail.gmail.com>
	<55034A48.4040409@2ndquadrant.com>
	<CANwLwavsL-+SDRB7VKxQ_OJq-T=MVQV6T6qH5Aug9PaSWt2C0w@mail.gmail.com>
	<CACKkDGHOnb2efYvLj557E5pSuzS+Wmu9dqG3Z=b_dbYhpi7muQ@mail.gmail.com>
 <CAOR=d=2L86fB+HWX8h078tYsd7LVKKFPQb=jfd8YNRU1Fc7mUA@mail.gmail.com>
 <849e75d9463938372dd4c516f5c5d89c@mail.gmail.com>
 <55037CEA.5050906@2ndquadrant.com> <55073272.20209@BlueTreble.com>
 <55074424.9050506@2ndquadrant.com> <55076FFB.9090105@BlueTreble.com>
 <c5231342781287ff8cbc9ac1f20ff036@mail.gmail.com>
In-Reply-To: <c5231342781287ff8cbc9ac1f20ff036@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Hi,

On 17.3.2015 08:41, Vivekanand Joshi wrote:
> Hi Guys,
> 
> Next level of query is following:
> 
> If this works, I guess 90% of the problem will be solved.
> 
> SELECT
>                     COUNT(DISTINCT TARGET_ID)
>                 FROM
>                     S_V_F_PROMOTION_HISTORY_EMAIL PH
>                     INNER JOIN S_V_D_CAMPAIGN_HIERARCHY CH
>                         ON PH.TOUCHPOINT_EXECUTION_ID =
> CH.TOUCHPOINT_EXECUTION_ID
>                 WHERE
>                     1=1
>                     AND SEND_DT >= '2014-03-13'
>                     AND SEND_DT <= '2015-03-14'
> 
> 
> In this query, I am joining two views which were made earlier with CTEs. I
> have replaced the CTE's with subqueries. The view were giving me output in
> around 5-10 minutes and now I am getting the same result in around 3-4
> seconds.
> 
> But when I executed the query written above, I am again stuck. I am
> attaching the query plan as well the link.
> 
> http://explain.depesz.com/s/REeu
> 
> I can see most of the time is spending inside a nested loop and total
> costs comes out be cost=338203.81..338203.82.

Most of that cost comes from this:

Seq Scan on s_f_promotion_history base (cost=0.00..283,333.66 rows=1
width=32)
  Filter: ((send_dt >= '2014-03-13 00:00:00'::timestamp without time
zone) AND (send_dt <= '2015-03-14 00:00:00'::timestamp without time


That's a bit weird, I guess. If you analyze this part of the query
separately, i.e.

EXPLAIN ANALYZE SELECT * FROM s_f_promotion_history
 WHERE (send_dt >= '2014-03-13 00:00:00')
   AND (send_dt <= '2015-03-14 00:00:00')

what do you get?

I suspect it's used in EXISTS, i.e. something like this:

... WHERE EXISTS (SELECT * FROM s_f_promotion_history
                   WHERE ... send_dt conditions ...
                     AND touchpoint_execution_id =
     s_f_touchpoint_execution_status_history_1.touchpoint_execution_id)

and this is transformed into a nested loop join. If there's a
misestimate, this may be quite expensive - try to create index on

   s_f_promotion_history (touchpoint_execution_id, send_date)


regards

-- 
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance