Re: Redundant sub query triggers slow nested loop left join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "henk de wit" <henk53602(at)hotmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Redundant sub query triggers slow nested loop left join
Date: 2007-04-22 20:42:33
Message-ID: 10143.1177274553@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"henk de wit" <henk53602(at)hotmail(dot)com> writes:
> I understand the above looks like a complicated mess, but would you
> have any pointers of what I could possibly do next to force a better plan?

Taking a closer look, it seems the problem is the underestimation of the
number of rows resulting from this relation scan:

> -> Bitmap Heap Scan on
> banners_links (cost=11.43..954.03 rows=2 width=73) (actual
> time=0.128..1.069 rows=359 loops=1)
> Recheck Cond: (merchant_id = 5631)
> Filter: ((status)::text = '0'::text)
> -> Bitmap Index Scan on
> banners_links_merchant_id_idx (cost=0.00..11.43 rows=424 width=0) (actual
> time=0.089..0.089 rows=424 loops=1)
> Index Cond: (merchant_id = 5631)

You might be able to improve matters by increasing the statistics target
for this table. I have a bad feeling though that the problem may be
lack of cross-column statistics --- the thing is evidently assuming
that only about 1 in 200 rows have status = '0', which might be accurate
as a global average but not for this particular merchant. What exactly
is the relationship between status and merchant_id, anyway?

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message henk de wit 2007-04-22 22:39:04 Re: Redundant sub query triggers slow nested loop left join
Previous Message henk de wit 2007-04-22 20:22:22 Re: Redundant sub query triggers slow nested loop left join