Re: 8.2 and 8.3 postgresql.conf oddity

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 <guillaume(dot)smet(at)gmail(dot)com> 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!