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