Re: Huge overestimation in rows expected results in bad plan - Mailing list pgsql-performance

From bricklen
Subject Re: Huge overestimation in rows expected results in bad plan
Date
Msg-id AANLkTinse1b0jgKi9jBFUQTV37fT9XLHwL-FTUhrx7yR@mail.gmail.com
Whole thread Raw
In response to Re: Huge overestimation in rows expected results in bad plan  (Andy Colson <andy@squeakycode.net>)
List pgsql-performance
On Tue, Nov 9, 2010 at 2:48 PM, Andy Colson <andy@squeakycode.net> wrote:
> On 11/9/2010 3:26 PM, bricklen wrote:
>
>>          ->   Seq Scan on conversionrejected cr  (cost=0.00..191921.82
>> rows=11012682 width=31) (actual time=0.003..1515.816 rows=11012682
>> loops=72)
>>  Total runtime: 292668.992 ms
>>
>
> Looks like the table stats are ok.  But its doing a sequential scan. Are you
> missing an index?
>
> Also:
>
> http://explain.depesz.com/
>
> is magic.
>
> -Andy
>

The PK is on the conversionrejected table in all three databases I
tested (I also tested our Greenplum datawarehouse). The "idconversion"
attribute is a bigint in both tables, so it's not a type mismatch.

\d conversionrejected
  Table "public.conversionrejected"
     Column     |  Type  | Modifiers
----------------+--------+-----------
 idconversion   | bigint | not null
 rejectedreason | text   | not null
Indexes:
    "conversionrejected_pk" PRIMARY KEY, btree (idconversion)

Yeah, that explain visualizer from depesz is a handy tool, I use frequently.

pgsql-performance by date:

Previous
From: Andy Colson
Date:
Subject: Re: Huge overestimation in rows expected results in bad plan
Next
From: "Kevin Grittner"
Date:
Subject: Re: anti-join chosen even when slower than old plan