Re: Planner constants for RAM resident databases - Mailing list pgsql-performance

From Emil Briggs
Subject Re: Planner constants for RAM resident databases
Date
Msg-id 200507020944.07339.emil@baymountain.com
Whole thread Raw
In response to Re: Planner constants for RAM resident databases  (John A Meinel <john@arbash-meinel.com>)
Responses Re: Planner constants for RAM resident databases
List pgsql-performance
> When you do "explain analyze" of a query that you have difficulties
> with, how are the planner's estimates. Are the estimated number of rows
> about equal to the actual number of rows?

Some of them are pretty far off. For example

  ->  Merge Left Join  (cost=9707.71..13993.52 rows=1276 width=161) (actual
time=164.423..361.477 rows=49 loops=1)

I tried setting enable_merge_joins to off and that made the query about three
times faster. It's using a hash join instead.

pgsql-performance by date:

Previous
From: Madison Kelly
Date:
Subject: B-Tree index not being used
Next
From: Tom Lane
Date:
Subject: Re: B-Tree index not being used