On 04/13/12 12:40 PM, mboldi@prospectiv.com wrote:
> Aggregate (cost=1689951.65..1689951.66 rows=1 width=0)
> -> Hash Join (cost=644.62..1687656.17 rows=918194 width=0)
> Hash Cond: (a.email_a = o.email)
> -> Subquery Scan on a (cost=0.00..1654854.18 rows=9149 width=64)
> Filter: ((a.memberid_a> a.memberid_b) AND (a.email_a =
> a.email_b) AND (length(a.email_a)> 0))
> -> Limit (cost=0.00..1325501.10 rows=16467654 width=690)
> -> Nested Loop (cost=0.00..1325501.10 rows=16467654
> width=690)
> -> Seq Scan on lgen_fraud_members12282
> (cost=0.00..1597.14 rows=5381 width=345)
> Filter: ((regcomplete<> (-8)) AND (dateid
>> >= 5938))
> -> Index Scan using lgah11_12282 on
> lgen_fraud_members12282 (cost=0.00..123.62 rows=3060 width=345)
> Index Cond:
> ((staging.lgen_fraud_members12282.dateid>=
> staging.lgen_fraud_members12282.dateid) AND
> (staging.lgen_fraud_members12282.memberid>
> staging.lgen_fraud_members12282.memberid))
> -> Hash (cost=393.72..393.72 rows=20072 width=32)
> -> Seq Scan on lgen_fraud_email o (cost=0.00..393.72
> rows=20072 width=32)
without seeing the query, I can only suggest that it appears the LIMIT
is inside of a nested query or something, as it looks like it was
applied prior to additional filtering and joining.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
