Emil,
> -> Merge Left Join (cost=9707.71..13993.52 rows=1276 width=161)
> (actual time=164.423..361.477 rows=49 loops=1)
That would indicate that you need to either increase your statistical
sampling (SET STATISTICS) or your frequency of running ANALYZE, or both.
--
--Josh
Josh Berkus
Agl
> 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=1
Emil Briggs wrote:
I just mentioned random_page_cost, but you should also tune
effective_cache_size, since that is effectively most of your RAM. It
depends what else is going on in the system, but setting it as high as
say 12-14GB is probably reasonable if it is a dedicated machine. With
random_
Emil Briggs wrote:
I'm working with an application where the database is entirely resident in RAM
(the server is a quad opteron with 16GBytes of memory). It's a web
application and handles a high volume of queries. The planner seems to be
generating poor plans for some of our queries which I ca
On Fri, Jul 01, 2005 at 09:59:38PM -0400, Emil Briggs wrote:
> I'm working with an application where the database is entirely resident in
> RAM
> (the server is a quad opteron with 16GBytes of memory). It's a web
> application and handles a high volume of queries. The planner seems to be
> gen
I'm working with an application where the database is entirely resident in RAM
(the server is a quad opteron with 16GBytes of memory). It's a web
application and handles a high volume of queries. The planner seems to be
generating poor plans for some of our queries which I can fix by raising
