Re: Feature Request --- was: PostgreSQL Performance Tuning

From: david@lang.hm
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
Date: ,
Msg-id: Pine.LNX.4.64.0705031849250.6380@asgard.lang.hm
(view: Whole thread, Raw)
In response to: Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno)
List: pgsql-performance

Tree view

Re: [GENERAL] PostgreSQL Performance Tuning  (Steve Crawford, )
 Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
  Re: Feature Request --- was: PostgreSQL Performance Tuning  (Tom Lane, )
   Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
    Re: Feature Request --- was: PostgreSQL Performance Tuning  (Michael Stone, )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  (Mark Lewis, )
      Re: Feature Request --- was: PostgreSQL Performance Tuning  (Michael Stone, )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  (Jim Nasby, )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  (Dan Harris, )
      Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
       Re: Feature Request --- was: PostgreSQL Performance Tuning  (Greg Smith, )
        Re: Feature Request --- was: PostgreSQL Performance Tuning  ("Craig A. James", )
         Re: Feature Request --- was: PostgreSQL Performance Tuning  (Kevin Hunter, )
          Re: Feature Request --- was: PostgreSQL Performance Tuning  (Greg Smith, )
        Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
         Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
          Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
           Re: Feature Request --- was: PostgreSQL Performance Tuning  (Sebastian Hennebrueder, )
            Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
             Re: Feature Request --- was: PostgreSQL Performance Tuning  (Sebastian Hennebrueder, )
             Re: Feature Request --- was: PostgreSQL Performance Tuning  (Mark Kirkwood, )
              Re: Feature Request --- was: PostgreSQL Performance Tuning  (Sebastian Hennebrueder, )
             Re: Feature Request --- was: PostgreSQL Performance Tuning  (Jim Nasby, )
              Re: Feature Request --- was: PostgreSQL Performance Tuning  (Andreas Kostyrka, )
         Re: Feature Request --- was: PostgreSQL Performance Tuning  (Greg Smith, )
          Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
          Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
           Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
            Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
             Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
              Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
               Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
                Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
                 Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
                  Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )
                   Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
           Re: Feature Request --- was: PostgreSQL Performance Tuning  (Greg Smith, )
            Re: Feature Request --- was: PostgreSQL Performance Tuning  (Michael Stone, )
             Re: Feature Request --- was: PostgreSQL Performance Tuning  (Greg Smith, )
              Re: Feature Request --- was: PostgreSQL Performance Tuning  ("Steinar H. Gunderson", )
       Re: Feature Request --- was: PostgreSQL Performance Tuning  (Ron, )
      Re: Feature Request --- was: PostgreSQL Performance Tuning  (Bill Moran, )
       Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
       Re: Feature Request --- was: PostgreSQL Performance Tuning  (Dan Harris, )
        Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus, )
         Re: Feature Request --- was: PostgreSQL Performance Tuning  (, )
    Re: Feature Request --- was: PostgreSQL Performance Tuning  (Tom Lane, )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  ("H.J. Sanders", )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  (Kevin Hunter, )
      Re: Feature Request --- was: PostgreSQL Performance Tuning  (Ray Stell, )
    Re: Feature Request --- was: PostgreSQL Performance Tuning  ("Harald Armin Massa", )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  ("Jonah H. Harris", )
      Re: Feature Request --- was: PostgreSQL Performance Tuning  ("Harald Armin Massa", )
     Re: Feature Request --- was: PostgreSQL Performance Tuning  (Carlos Moreno, )

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



pgsql-performance by date:

From: Tobias Brox
Date:
Subject: Re: pg_stat_* collection
From: Michael Stone
Date:
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning