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 13:09:34
Message-ID: 42D5128E.70104@archonet.com (view raw or flat)
Thread:
Lists: pgsql-general
Roman Neuhauser wrote:
>>Because you don't have an index on "base" for the files table.
> 
>  
>     I added one, ran vacuum full analyze fix.files, and:
> 
>     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)
> 
>     Which is exactly what I expected. Using left prefix of a multicolumn
>     index normally works just fine, thank you.

Couldn't figure out what you meant here - had to go back and re-read 
your index definitions. Sorry - missed the (base, ...) on the front of 
base_storename_idx.

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.

--
   Richard Huxton
   Archonet Ltd

In response to

Responses

pgsql-general by date

Next:From: Janning VygenDate: 2005-07-13 13:20:58
Subject: Re: getting the ranks out of items with SHARED
Previous:From: Michael FuhrDate: 2005-07-13 13:07:56
Subject: Re: pgcrypto : how to get SHA1(string) as a 40-char string, NOT binary string?

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