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.smet@gmail.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!

Hi Harald,

On Jan 23, 2008 1:36 PM, Harald Armin Massa <haraldarminmassa@gmail.com> wrote:

that should be regarded more to be a feature then a bug:

That's not my point :). It's just that the comments are misleading or
at least a bit absurd.

--
Guillaume

On Jan 23, 2008 11:50 AM, Guillaume Smet <guillaume.smet@gmail.com> wrote:

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.

Do you think it should be "same arbitrary scale as above"?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

"Guillaume Smet" <guillaume.smet@gmail.com> writes:

#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.

What do you find odd about it? Whatever scale you choose to think these
values are in, they all have to be on the same scale.

regards, tom lane

On Jan 23, 2008 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

What do you find odd about it? Whatever scale you choose to think these
values are in, they all have to be on the same scale.

So they are not defined in relation compared to the sequential page
fetch cost as they were before? I mean, if I change seq_page_cost
only, it doesn't change the overall behaviour?

--
Guillaume

"Guillaume Smet" <guillaume.smet@gmail.com> writes:

On Jan 23, 2008 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

What do you find odd about it? Whatever scale you choose to think these
values are in, they all have to be on the same scale.

So they are not defined in relation compared to the sequential page
fetch cost as they were before?

Well, you could choose to stick to the traditional scale, in which
seq_page_cost is always 1.0 and everything else is relative to that.
Or you could try to make them all measure actual milliseconds on
your actual machine. Or something else.

I mean, if I change seq_page_cost
only, it doesn't change the overall behaviour?

Certainly it would. If you multiply *all* the cost constants by the same
factor, then the behavior wouldn't change.

regards, tom lane