Re: Why does row estimation on nested loop make no sense to me - Mailing list pgsql-general

From Jeff Amiel
Subject Re: Why does row estimation on nested loop make no sense to me
Date
Msg-id 1368815476.14515.YahooMailNeo@web161404.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: Why does row estimation on nested loop make no sense to me  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Why does row estimation on nested loop make no sense to me  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-general



> explain analyze
> select  era.child_entity  from entity_rel era  join user_entity ue on ue.entity_id = era.parent_entity and
ue.user_id=12345
>
> Nested Loop  (cost=0.00..2903.37 rows=29107 width=4) (actual time=0.028..0.274 rows=201 loops=1)
>   ->  Index Only Scan using entity_pk on user_entity ue  (cost=0.00..62.68 rows=2 width=4) (actual time=0.011..0.012
rows=1loops=1) 
>         Index Cond: (user_id = 12345)
>         Heap Fetches: 1
>   ->  Index Scan using rel_parent on entity_rel era  (cost=0.00..1261.85 rows=317 width=8) (actual time=0.013..0.164
rows=201loops=1) 
>         Index Cond: (parent_entity = ue.entity_id)
> Total runtime: 0.361 ms

>Have you tried analyze (it's probably a case of insufficient/outdated
>statistics to planner's disposal) or probably consider changing
>default_statistics_target?


Again - my question revolves not around the whether or not I am getting good or bad estimates - my question is related
tothe fact that the nested-loop row estimation does not appear to be derived from the nodes below it - it is off by
ordersof magnitude.  I've never seen this before. 
That aside, yes - I did analyze and tweak stats target during experimentation - no change.


pgsql-general by date:

Previous
From: Achilleas Mantzios
Date:
Subject: Re: Comunication protocol
Next
From: Alfonso Afonso
Date:
Subject: Re: Best practice on inherited tables