Grzegorz Jaskiewicz wrote:
>
> On 25 Feb 2011, at 13:18, Robert Haas wrote:
>
> > People coming from Oracle are not favorably
> > impressed either by the amount of monitoring data PostgreSQL can
> > gather or by the number of knobs that are available to fix problems
> > when they occur. We don't need to have as many knobs as Oracle and we
> > probably don't want to, and for that matter we probably couldn't if we
> > did want to for lack of manpower, but that doesn't mean we should have
> > none.
>
> Still, having more data a user can probe would be nice.
>
> I wonder why everyone avoids Microsoft's approach to the subject. Apparently, they go in the 'auto-tune as much as
possible'direction.
> And tests we did a while ago, involving asking team from Microsoft and a team from oracle to optimise set of queries
forthe same set of data (bookies data, loads of it) showed that the auto-tuning Microsoft has in their
> sql server performed much better than a team of over-sweating oracle dba's.
>
> In my current work place/camp we have many deployments of the same system, over different types of machines, each
withdifferent customer data that vary so much that queries need to be rather generic.
> Postgresql shows its strength with planner doing a good job for different variants of data, however we do a very
littletweaking to the configuration parameters. Just because it is just too hard to overlook all of them.
> I guess that the systems could behave much better, but no one is going to tweak settings for 50 different
installationsover 50 different type of data and 50 different sets of hardware.
> If there was even a tiny amount of automation provided in the postgresql, I would welcome it with open arms.
I totally agree. If we add a tuning parameter that does 10x better than
automatic, but only 1% of our users use it, we would be better off,
overall, with the automatic tuning. See my blog post which talks about
the same tradeoff when adding configuration variables:
http://momjian.us/main/blogs/pgblog/2009.html#January_10_2009
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +