Skip site navigation (1) Skip section navigation (2)

Re: 7.4.7: strange planner decision

From: Richard Huxton <dev(at)archonet(dot)com>
To: Roman Neuhauser <neuhauser(at)sigpipe(dot)cz>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 7.4.7: strange planner decision
Date: 2005-07-13 14:10:16
Message-ID: 42D520C8.9010204@archonet.com (view raw or flat)
Thread:
Lists: pgsql-general
Roman Neuhauser wrote:
> # dev(at)archonet(dot)com / 2005-07-13 14:09:34 +0100:
> 
>>Roman Neuhauser wrote:
>>
>>>   callrec32=# \d fix.files
>>>                 Table "fix.files"
>>>    Column |          Type          | Modifiers
>>>   --------+------------------------+-----------
>>>    dir    | character varying(255) |
>>>    base   | character varying(255) |
>>>   Indexes:
>>>       "base_storename_idx" btree (base, ((((dir)::text || '/'::text) || 
>>>       (base)::text)))
>>>       "ff_baseonly_idx" btree (base)
>>>       "ff_storename_idx" btree (((((dir)::text || '/'::text) || 
>>>       (base)::text)))
>>>
>>>   callrec32=# explain select fd.base from fix.dups fd join fix.files ff 
>>>   using (base);
>>>                                    QUERY PLAN
>>>   ----------------------------------------------------------------------------
>>>    Hash Join  (cost=5340.00..292675.06 rows=176161 width=44)
>>>      Hash Cond: (("outer".base)::text = ("inner".base)::text)
>>>      ->  Seq Scan on files ff  (cost=0.00..117301.58 rows=5278458 
>>>      width=41)
>>>      ->  Hash  (cost=3436.60..3436.60 rows=176160 width=44)
>>>            ->  Seq Scan on dups fd  (cost=0.00..3436.60 rows=176160 
>>>            width=44)
>>>   (5 rows)
> 
> 
>>What happens to the plan if you SET enable_seqscan=false; first? It's 
>>presumably getting the row-estimate right, so unless there's terrible 
>>correlation on "base" in the files table I can only assume it's getting 
>>the cost estimates horribly wrong.
> 
> 
> callrec32=# SET enable_seqscan=false;
> SET
> callrec32=# explain select fd.base from fix.dups fd join fix.files ff using (base);
>                                          QUERY PLAN                             
> --------------------------------------------------------------------------------------------
>  Nested Loop  (cost=0.00..1066990.93 rows=176161 width=44)
>    ->  Index Scan using dups_base_key on dups fd  (cost=0.00..5570.86 rows=176160 width=44)
>    ->  Index Scan using ff_baseonly_idx on files ff  (cost=0.00..6.01 rows=1 width=41)
>          Index Cond: (("outer".base)::text = (ff.base)::text)

OK - so it thinks the cost of this plan will be about 1 million, whereas 
the old plan was 290 thousand. The question is - why?
What are your planner settings? Ch 16.4.4.2 here
http://www.postgresql.org/docs/7.4/static/runtime-config.html#RUNTIME-CONFIG-QUERY

I'm guessing something to do with cpu_index_tuple_cost or random_page_cost.
--
   Richard Huxton
   Archonet Ltd

In response to

pgsql-general by date

Next:From: Roman NeuhauserDate: 2005-07-13 14:14:27
Subject: Re: 7.4.7: strange planner decision
Previous:From: Tom LaneDate: 2005-07-13 14:08:01
Subject: Re: Array as parameter for plpgsql function

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group