From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
Cc: | Alex Solovey <a(dot)solovey(at)gmail(dot)com>, "Rodrigo E(dot) De León Plicet" <rdeleonp(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problem with planner choosing nested loop |
Date: | 2008-04-03 07:03:38 |
Message-ID: | 47F4814A.2090909@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alban Hertroys wrote:
>
> On Apr 2, 2008, at 9:02 PM, Alex Solovey wrote:
>> The reduced database example has the same problem in EXPLAIN ANALYZE
>> as production one, here:
>>
>> Seq Scan on bar (cost=0.00..393.07 rows=1 width=4) (actual
>> time=0.098..3.561 rows=24 loops=1)
>
> Hang on... You prefer sequential scans because indexes make your
> database too slow, but you don't want a sequential scan now? What kind
> of solution do you expect then? An oracle maybe?
It sounds to me like the issue is with *multiple* sequential scans
inside a nested loop instead of the single sequential scan expected.
The quoted explain line reflects a claimed cost misestimation, rather
than being a claim that sequential scans in general are not desired.
> You will need an index if this query is too slow for you, or you will
> have to live with the slowness of this query. Pick one ;)
He's already noted that it's preferable to avoid adding indexes due to
insert/update performance issues.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-04-03 07:12:58 | Re: modules |
Previous Message | Alban Hertroys | 2008-04-03 06:34:29 | Re: Problem with planner choosing nested loop |