Re: AW: [HACKERS] Some notes on optimizer cost estimates

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: [HACKERS] Some notes on optimizer cost estimates
Date: 2000-01-25 23:16:01
Message-ID: Pine.LNX.4.21.0001250956070.345-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2000-01-24, Zeugswetter Andreas SB mentioned:

>
> > > Couldn't we test some of these parameters inside configure and set
> > > them there?
> >
> > If we could figure out a reasonably cheap way of estimating these
> > numbers, it'd be worth setting up custom values at installation time.
>
> Imho this whole idea is not so good. (Sorry)
>
> My points are:
> 1. even if it is good for an optimizer to be smart,
> it is even more important, that it is predictable

ISTM that by the nature of things the most important capability of an
optimizer is to yield optimal results. This, however, does not have to be
mutually exclusive with predictability. If you estimate some CPU and disk
parameters and write them into a config file, then you can always give
this config file to a bug fixer. It will still work on his machine, just
less than optimally.

> 2. I compile on test machine, production is completely different
> (more processors, faster disks and controllers)

You're completely right. This has no place in configure. It will have to
be a separate tool which you can run after building and installing.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-01-25 23:16:15 Re: [HACKERS] Some notes on optimizer cost estimates
Previous Message Peter Eisentraut 2000-01-25 23:15:47 --enable-debug