Re: 7.4.7: strange planner decision - Mailing list pgsql-general

From Richard Huxton
Subject Re: 7.4.7: strange planner decision
Date
Msg-id 42D501AB.5080306@archonet.com
Whole thread Raw
In response to 7.4.7: strange planner decision  (Roman Neuhauser <neuhauser@sigpipe.cz>)
Responses Re: 7.4.7: strange planner decision
List pgsql-general
Roman Neuhauser wrote:
> Why does the planner want to crawl the table that has 5M rows instead of the one
> with 176k rows? Both tables are freshly vacuum-full-analyzed.

Because you don't have an index on "base" for the files table.

> 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_storename_idx" btree (((((dir)::text || '/'::text) || (base)::text)))

A couple of indexes, but none simple on "base", so it can't be used for
the join.

--
   Richard Huxton
   Archonet Ltd

pgsql-general by date:

Previous
From: Janning Vygen
Date:
Subject: strange error with temp table: pg_type_typname_nsp_index
Next
From: David Pratt
Date:
Subject: Array as parameter for plpgsql function