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

In response to

• 7.4.7: strange planner decision at 2005-07-13 11:12:21 from Roman Neuhauser

Responses

• Re: 7.4.7: strange planner decision at 2005-07-13 12:48:27 from Roman Neuhauser

pgsql-general by date

Next:	From: David Pratt	Date: 2005-07-13 12:00:47
	Subject: Array as parameter for plpgsql function
Previous:	From: Janning Vygen	Date: 2005-07-13 11:44:54
	Subject: strange error with temp table: pg_type_typname_nsp_index