On Tue, May 21, 2013 at 12:43 AM, Jeff Amiel wrote:
> Thanks much!
> (sorry for top-posting, yahoo email sucks)
>
I wonder if you could arrive at some conclusions with the statistics
(pg_stats) you have and the join selectivity formulas described in the
referred documentation link. I would like t
Thanks much!
(sorry for top-posting, yahoo email sucks)
- Original Message -
From: Amit Langote
To: Jeff Amiel
Cc: "dep...@depesz.com" ; "pgsql-general@postgresql.org"
Sent: Monday, May 20, 2013 9:51 AM
Subject: Re: [GENERAL] Why does row estimation on nested l
I also found one other discussion which has similar issues addressed:
http://postgresql.1045698.n5.nabble.com/Bogus-nestloop-rows-estimate-in-8-4-7-td5710254.html
--
Amit Langote
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://
On Mon, May 20, 2013 at 11:01 PM, Jeff Amiel wrote:
> Ok - I agree -
>
> Can somebody help me understand where the row estimates come from on a
> nested-loop operation in postgres then?
>
In case you haven't noticed already in the documentation, there are
following lines:
"... It might appear f
ubject: Re: [GENERAL] Why does row estimation on nested loop make no sense
to me
Not sure if it helps, but it's apparently not a very rare thing.
Quick analysis on data from explain.depesz.com showed that > 12% of
plans with nested loop have such estimate.
Couple of examples:
http://explai
Not sure if it helps, but it's apparently not a very rare thing.
Quick analysis on data from explain.depesz.com showed that > 12% of
plans with nested loop have such estimate.
Couple of examples:
http://explain.depesz.com/s/Qm4
http://explain.depesz.com/s/qmW
http://explain.depesz.com/s/qnG
http:
- Original Message -
From: Amit Langote
To: Jeff Amiel
Cc: "pgsql-general@postgresql.org"
Sent: Friday, May 17, 2013 2:21 PM
Subject: Re: [GENERAL] Why does row estimation on nested loop make no sense to
me
>> explain analyze
>> select era.child_entity fro
>> 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 o
> 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 u
On Sat, May 18, 2013 at 1:47 AM, Jeff Amiel wrote:
>
>
>
>
> - Original Message -
> From: Amit Langote
> To: Jeff Amiel
> Cc: "pgsql-general@postgresql.org"
> Sent: Friday, May 17, 2013 11:37 AM
> Subject: Re: [GENERAL] Why does row estimati
- Original Message -
From: Amit Langote
To: Jeff Amiel
Cc: "pgsql-general@postgresql.org"
Sent: Friday, May 17, 2013 11:37 AM
Subject: Re: [GENERAL] Why does row estimation on nested loop make no sense to
me
On Sat, May 18, 2013 at 1:25 AM, Jeff Amiel wrote:
> O
> Can you provide a self-contained test case that does this?
That response scares me.
:)
I can try - Every other table set (small, easy to experiment with) returns
results as expected -
Is the implication that this looks 'unusual'?
--
Sent via pgsql-general mailing list (pgsql-general@po
On Sat, May 18, 2013 at 1:25 AM, Jeff Amiel wrote:
> On most nested loops that I do explain/explain analyze on, the row estimation
> for the nested-loop itself is a product of the inner nodes of the nested loop.
> However in this case, I am stumped!
>
> explain
> select era.child_entity from en
Jeff Amiel writes:
> How can the estimated number of rows for the nested loop node EXCEED the
> product of the 2 row estimates of the tables being joined?
> Not only does it exceed it - but it is orders of magnitude greater.
Can you provide a self-contained test case that does this?
14 matches
Mail list logo
