On Wed, Nov 15, 2017 at 03:03:39PM +0530, Samir Magar wrote: > I am having performance issues with one of the query. > The query is taking 39 min to fetch 3.5 mil records. > > I want to reduce that time to 15 mins. > could you please suggest something to its performance? > "HashAggregate (cost=4459.68..4459.69 rows=1 width=27) (actual time=2890035.403..2892173.601 rows=3489861 loops=1)" Looks to me like the problem is here: > " -> Index Only Scan using idxdq7 on dlr_qlfy (cost=0.43..4.45 ROWS=1 width=16) (actual time=0.009..0.066 ROWS=121 loops=103987)" > " Index Cond: ((qlfy_grp_id = dlr_grp.dlr_grp_id) AND (qlf_flg = 'N'::bpchar) AND (cog_grp_id = dlr_grp_dlr_xref_1.dlr_grp_id))" > " Heap Fetches: 0" Returning 100x more rows than expected and bubbling up through a cascade of nested loops. Are those 3 conditions independent ? Or, perhaps, are rows for which "qlfy_grp_id=dlr_grp.dlr_grp_id" is true always going to have "cog_grp_id = dlr_grp_dlr_xref_1.dlr_grp_id" ? Even if it's not "always" true, if rows which pass the one condition are more likely to pass the other condition, this will cause an underestimate, as obvserved. You can do an experiment SELECTing just from those two tables joined and see if you can reproduce the problem with poor rowcount estimate (hopefully in much less than 15min). If you can't drop one of the two conditions, you can make PG treat it as a single condition for purpose of determining expected selectivity, using a ROW() comparison like: ROW(qlfy_grp_id, cog_grp_id) = ROW(dlr_grp.dlr_grp_id, dlr_grp_dlr_xref_1.dlr_grp_id) If you're running PG96+ you may also be able to work around this by adding FKs. Justin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
