Roman Neuhauser wrote:
# dev@archonet.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) |
bas
Richard Huxton writes:
> 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.
I think you'll f
# [EMAIL PROTECTED] / 2005-07-13 15:58:09 +0200:
> # dev@archonet.com / 2005-07-13 14:09:34 +0100:
> > Roman Neuhauser wrote:
> > >callrec32=# \d fix.files
> > > Table "fix.files"
> > > Column | Type | Modifiers
> > >++-
# dev@archonet.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) |
> >
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
+-
# dev@archonet.com / 2005-07-13 12:57:31 +0100:
> 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.
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
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.
7.4.7 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 20041212 (Red
Hat 3.4.3-9.EL4)
callrec32=# explain select fd.base from fix.dups fd join f
