On Thu, 3 May 2007, Carlos Moreno wrote:
>
>> > error like this or even a hundred times this!! Most of the time
>> > you wouldn't, and definitely if the user is careful it would not
>> > happen --- but it *could* happen!!! (and when I say could, I
>> > really mean: trust me, I have actually seen it happen)
>> Part of my claim is that measuring real-time you could get an
>>
>> if you have errors of several orders of magnatude in the number of loops
>> it can run in a given time period then you don't have something that you
>> can measure to any accuracy (and it wouldn't matter anyway, if your loops
>> are that variable, your code execution would be as well)
>
> Not necessarily --- operating conditions may change drastically from
> one second to the next; that does not mean that your system is useless;
> simply that the measuring mechanism is way too vulnerable to the
> particular operating conditions at the exact moment it was executed.
>
> I'm not sure if that was intentional, but you bring up an interesting
> issue --- or in any case, your comment made me drastically re-think
> my whole argument: do we *want* to measure the exact speed, or
> rather the effective speed under normal operating conditions on the
> target machine?
>
> I know the latter is almost impossible --- we're talking about an estimate
> of a random process' parameter (and we need to do it in a short period
> of time) ... But the argument goes more or less like this: if you have a
> machine that runs at 1000 MIPS, but it's usually busy running things
> that in average consume 500 of those 1000 MIPS, would we want PG's
> configuration file to be obtained based on 1000 or based on 500 MIPS???
> After all, the CPU is, as far as PostgreSQL will be able see, 500 MIPS
> fast, *not* 1000.
>
> I think I better stop, if we want to have any hope that the PG team will
> ever actually implement this feature (or similar) ... We're probably just
> scaring them!! :-)
simpler is better (or perfect is the enemy of good enough)
if you do your sample over a few seconds (or few tens of seconds) things
will average out quite a bit.
the key is to be going for a reasonable starting point. after that then
the full analysis folks can start in with all their monitoring and
tuneing, but the 80/20 rule really applies here. 80% of the gain is from
getting 'fairly close' to the right values, and that should only be 20% of
the full 'tuneing project'
David Lang