Thread: 8.2 and 8.3 postgresql.conf oddity
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
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 =3D 1.0 # measured on an arbitrary scale > #random_page_cost =3D 4 # same scale as above > #cpu_tuple_cost =3D 0.01 # same scale as above > #cpu_index_tuple_cost =3D 0.005 # same scale as above > #cpu_operator_cost =3D 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 =3D 2 # units are one sequential page= fetch > # cost > cpu_tuple_cost =3D 0.01 # (same) > cpu_index_tuple_cost =3D 0.001 # (same) > cpu_operator_cost =3D 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 > --=20 GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Stra=DFe 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