sarlav kumar <[EMAIL PROTECTED]> writes:
> I have a query which does not use index scan unless I force postgres to use 
> index scan. I dont want to force postgres, unless there is no way of 
> optimizing this query.

The major issue seems to be in the sub-selects:

>                  ->  Seq Scan on merchant_purchase mp  (cost=0.00..95.39 
> rows=44 width=4) (actual time=2.37..2.58 rows=6 loops=619)
>                        Filter: (merchant_id = $0)

where the estimated row count is a factor of 7 too high.  If the
estimated row count were even a little lower, it'd probably have gone
for an indexscan.  You might get some results from increasing the
statistics target for merchant_purchase.merchant_id.  If that doesn't
help, I'd think about reducing random_page_cost a little bit.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to