Re: Performance issues

Hi Tomas,

This is what I am getting,

EXPLAIN ANALYZE SELECT * FROM s_f_promotion_history WHERE (send_dt >=
'2014-03-13 00:00:00');

QUERY
PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on s_f_promotion_history (cost=0.00..283333.66 rows=1 width=74)
(actual time=711.023..1136.393 rows=1338 loops=1)
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 zone))
Rows Removed by Filter: 9998662
Total runtime: 1170.682 ms

CREATE INDEX idx_pr_history ON
S_F_PROMOTION_HISTORY(touchpoint_execution_id, send_dt);

After Creating Index:

QUERY
PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using idx_pr_history on s_f_promotion_history
(cost=0.43..254028.45 rows=1 width=74) (actual time=375.796..604.587
rows=1338 loops=1)
Index Cond: ((send_dt >= '2014-03-13 00:00:00'::timestamp without time
zone) AND (send_dt <= '2015-03-14 00:00:00'::timestamp without time zone))
Total runtime: 604.733 ms

The query I gave you is the smallest query, it is using two views and both
the views I have changed by using subqueries instead of CTEs. When I join
these two views, it is not getting completed at all.

Explain analyze plan for view s_v_f_promotion_history_email:
http://explain.depesz.com/s/ure
Explain analyze plan for view s_v_d_campaign_hierarchy :
http://explain.depesz.com/s/WxI

Regards,
Vivek

-----Original Message-----
From: Tomas Vondra [mailto:tomas(dot)vondra(at)2ndquadrant(dot)com]
Sent: Tuesday, March 17, 2015 5:15 PM
To: vjoshi(at)zetainteractive(dot)com; Jim Nasby; Scott Marlowe; Varadharajan
Mukundan
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Performance issues

On 17.3.2015 12:07, Vivekanand Joshi wrote:
> EXPLAIN ANALYZE didn't give result even after three hours.

In that case the only thing you can do is 'slice' the query into smaller
parts (representing subtrees of the plan), and analyze those first. Look
for misestimates (significant differences between estimated and actual
row counts, and very expensive parts).

We can't do that, because we don't have your data or queries, and
without the explain analyze it's difficult to give advices.

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