> I'm seeing a lot of plans in my database that look like this: > It seems very strange for the planner to decide to build an in-memory > hash table on a column that is already indexed (the primary key, no > less!). But this is happening A LOT - I often see plans where a > majority of the joins are executed this way (and they're not all > self-joins either...). It seems like the planner is concluding that > it's going to need most or all of the pages in the table anyway, and > that building a hash table as it goes is quicker than reading the > index pages in from disk. On a simple query like the above, setting > enable_seqscan to off or random_page_cost to 1 generates the expected > plan: > Experimentation shows this is actually about 25% faster. But, this is > kind of a blunt instrument, and my attempts to fiddle with various > parameters have not been real succesful in generating better plans for > more complicated examples. > > Any suggestions/explanations? > > ...Robert Could you send the output of these two queries using "explain analyze" instead of plain explain? -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
