From: | bricklen <bricklen(at)gmail(dot)com> |
---|---|
To: | Andy Colson <andy(at)squeakycode(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Huge overestimation in rows expected results in bad plan |
Date: | 2010-11-09 22:59:02 |
Message-ID: | AANLkTinse1b0jgKi9jBFUQTV37fT9XLHwL-FTUhrx7yR@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Nov 9, 2010 at 2:48 PM, Andy Colson <andy(at)squeakycode(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-11-09 23:07:42 | Re: anti-join chosen even when slower than old plan |
Previous Message | Andy Colson | 2010-11-09 22:48:04 | Re: Huge overestimation in rows expected results in bad plan |