> 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?
