Skip site navigation (1) Skip section navigation (2)

Re: BUG #6787: Query planner estimates worng costs on nodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: gsaviane(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6787: Query planner estimates worng costs on nodes
Date: 2012-07-31 22:13:07
Message-ID: 16671.1343772787@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
gsaviane(at)gmail(dot)com writes:
> It seems the cost assigned to a sequential scan over 120 million records is
> too low or, on the other side, the cost assigned to two nested loop over
> three indexes is too high.

It looks from here like you are measuring a situation where
vb_product_readings is fully cached in RAM.  If that's the normal
situation in your database, then you ought to decrease the
random_page_cost setting to make the planner's cost estimates reflect
your reality.  The default setting is intended to model situations
where a fair amount of disk access is going to happen.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: lrDate: 2012-08-01 01:15:21
Subject: BUG #6788: Can't compile on mingw64-w32
Previous:From: gsavianeDate: 2012-07-31 15:06:36
Subject: BUG #6787: Query planner estimates worng costs on nodes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group