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

From: Andreas Kostyrka
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
Date: ,
Msg-id: 463D7E5A.7060007@kostyrka.org
(view: Whole thread, Raw)
In response to: Re: Feature Request --- was: PostgreSQL Performance Tuning  (Jim Nasby)
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, )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Only some problems that come to my mind with this:

a) Hardware is sometimes changed underhand without telling the customer.
Even for server-level hardware. (Been there.)

b) Hardware recommendations would get stale quickly. What use is a
hardware spec that specifies some versions of Xeons, when the supply
dries up. (the example is not contrived, certain versions of PG and
Xeons with certain usage patterns don't work that well. google for
context switch storms)

c) All that is depending upon the PG version too, so with every new
version somebody would have to reverify that the recommendations are
still valid. (Big example, partitioned tables got way better supported
in recent versions. So a setup that anticipated Seqscans over big tables
might suddenly perform way better. OTOH, there are some regressions
performance wise sometimes)

d) And to add insult to this, all that tuning (hardware and software
side) is sensitive to your workload. Before you start yelling, well,
have you ever rolled back an application version, because you notice
what stupidities the developers have added. (And yes you can try to
avoid this by adding better staging to your processes, but it's really
really hard to setup a staging environment that has the same performance
 characteristics as production.)

So, while it's a nice idea to have a set of recommended hardware setups,
I don't see much of a point. What makes a sensible database server is
not exactly a secret. Sizing slightly harder. And after that one enters
the realm of fine tuning the complete system. That does not end at the
socket on port 5432.

Andreas

Jim Nasby wrote:
> On May 4, 2007, at 12:11 PM, Josh Berkus wrote:
>> Sebastian,
>>> Before inventing a hyper tool, we might consider to provide 3-5 example
>>> szenarios for common hardware configurations. This consumes less time
>>> and be discussed and defined in a couple of days. This is of course not
>>> the correct option for a brandnew 20 spindle Sata 10.000 Raid 10 system
>>> but these are probably not the target for default configurations.
>>
>> That's been suggested a number of times, but some GUCs are really tied
>> to the
>> *exact* amount of RAM you have available.  So I've never seen how
>> "example
>> configurations" could help.
>
> Uh... what GUCs are that exacting on the amount of memory? For a decent,
> base-line configuration, that is.
> --
> Jim Nasby                                            
> EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPX5aHJdudm4KnO0RAorYAJ9XymZy+pp1oHEQUu3VGB7G2G2cSgCfeGaU
X2bpEq3aM3tzP4MYeR02D6U=
=vtPy
-----END PGP SIGNATURE-----


pgsql-performance by date:

From: Yudhvir Singh Sidhu
Date:
Subject: Re: How to Find Cause of Long Vacuum Times - NOOB Question
From: Robins
Date:
Subject: Re: Index not being used in sorting of simple table