Guillaume, that should be regarded more to be a feature then a bug:
within 8.1, the seq_page_cost was virtuelle fixed at 1; if you found that cost to be i.e. 12.123 as you measured "time to read in ms" with some other tool, you had to rescale all costs so that 12.123 is transformed to 1.0 Now that seq_page_cost is no longer fixed at 1.0; you do not have to do that rescaling. Leaving seq_page_cost at 1.0 gives you the same behaviour as before. Best wishes Harald On Jan 23, 2008 11:50 AM, Guillaume Smet <[EMAIL PROTECTED]> wrote: > Hi -bugs, > > I just noticed something odd in the Planner constants part of the 8.2 > and 8.3 postgresql.conf: > # - Planner Cost Constants - > > #seq_page_cost = 1.0 # measured on an arbitrary scale > #random_page_cost = 4 # same scale as above > #cpu_tuple_cost = 0.01 # same scale as above > #cpu_index_tuple_cost = 0.005 # same scale as above > #cpu_operator_cost = 0.0025 # same scale as above > > The "same scale as above" while we have an "arbitrary scale" on the > first line is a bit weird. > > 8.1 was: > random_page_cost = 2 # units are one sequential page fetch > # cost > cpu_tuple_cost = 0.01 # (same) > cpu_index_tuple_cost = 0.001 # (same) > cpu_operator_cost = 0.0025 # (same) > > Which seems better. > > AFAIK, the unit of random_page_cost and cpu_*_cost is now seq_page_cost. > > -- > Guillaume > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 fx 01212-5-13695179 - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned! ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
