Re: Query planner cost estimate less than the sum of its parts? - Mailing list pgsql-performance

From Gregory Stark
Subject Re: Query planner cost estimate less than the sum of its parts?
Date
Msg-id 877i7hc1ha.fsf@oxford.xeocode.com
Whole thread Raw
In response to Query planner cost estimate less than the sum of its parts?  ("Scott Carey" <scott@richrelevance.com>)
Responses Re: Query planner cost estimate less than the sum of its parts?  ("Scott Carey" <scott@richrelevance.com>)
List pgsql-performance
"Scott Carey" <scott@richrelevance.com> writes:

> Certainly, a cost estimate that is ... LESS than one of the sub sections of
> the query is wrong.   This was one hell of a broken query, but it at least
> should have taken an approach that was not a nested loop, and I'm curious if
> that choice was due to a bad estimate here.
>
> Nested Loop IN Join  (cost=0.00..3850831.86 rows=128266 width=8)

Because it's an IN join it doesn't have to run the inner join to completion.
Once it finds a match it can return the outer tuple and continue to the next
outer tuple.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: lru_multiplier and backend page write-outs
Next
From: "Scott Carey"
Date:
Subject: Re: Query planner cost estimate less than the sum of its parts?