Re: BUG #6587: Limit on a query is mis-documented

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