Re: Problem with planner choosing nested loop - Mailing list pgsql-general

From Craig Ringer
Subject Re: Problem with planner choosing nested loop
Date
Msg-id 47F4814A.2090909@postnewspapers.com.au
Whole thread Raw
In response to Re: Problem with planner choosing nested loop  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
List 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

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Problem with planner choosing nested loop
Next
From: "Albe Laurenz"
Date:
Subject: Re: Foreign keys causing conflicts leading toserialization failures