From: | "henk de wit" <henk53602(at)hotmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Redundant sub query triggers slow nested loop left join |
Date: | 2007-04-22 22:39:04 |
Message-ID: | BAY106-F24FD9F24DB0912FF7D4AD2F5540@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>You might be able to improve matters by increasing the statistics target
>for this table.
I have tried to increase the statistics for the status column to the maximum
of 1000. After that I performed an analyze, vacuum analyze and vacuum full
analyze on the table. Unfortunately this didn't seem to make any difference.
>I have a bad feeling though that the problem may be
>lack of cross-column statistics
I assume this isn't a thing that can be tweaked/increased in PG 8.2?
>--- 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?
The meaning is that a "banners_link" belongs to a merchant with the id
merchant_id. A "banners_link" can be disabled (status 1) or enabled (status
0). Globally about 1/3 of the banners_links have status 0 and 2/3 have
status 1. The 1 in 200 estimate is indeed way off.
For the merchant in question the numbers are a bit different though, but not
that much. Out of 424 rows total, 359 have status 0 and 65 have status 1.
_________________________________________________________________
FREE pop-up blocking with the new Windows Live Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
From | Date | Subject | |
---|---|---|---|
Next Message | henk de wit | 2007-04-22 22:58:15 | Re: Redundant sub query triggers slow nested loop left join |
Previous Message | Tom Lane | 2007-04-22 20:42:33 | Re: Redundant sub query triggers slow nested loop left join |