On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
<gj@pointblue.com.pl> 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.
I don't think *anyone* is avoiding that approach. There is almost
universal consensus here that auto-tuning is better than manual
tuning, even to the extent of being unwilling to add knobs to allow
manual tuning of settings we have no idea how to auto-tune and no
plans to auto-tune.
> 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.
What do you have in mind?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company