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
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 |
# 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.
I added
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 14:09:34 +0100:
Roman Neuhauser wrote:
callrec32=# \d fix.files
Table fix.files
Column | Type | Modifiers
++---
dir| character varying(255) |
base |
# [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
++---
Richard Huxton dev@archonet.com 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
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) |
base
