Re: WIP: cross column correlation ...

On 26 Feb 2011, at 14:45, Robert Haas wrote:

> On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
>>
>
> 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.
>
Perhaps one step further is required. To change some settings so that it can be auto-tuned better. There are some even
moredrastic steps that would have to be taken 
and I believe that Microsoft engineers had to take them. Steps back. For instance, if there is an issue with inability
tofind out how much of a table is in the cache, perhaps postgresql should 
have an option to turn off cached reads/writes completely and thus allow DBA to regulate that using the shared_buffers
setting.It doesn't sound great, but if you think about it 
I'm sure there are people willing to use it, if that adds a bit more auto-tunning to the server. I would even go a step
further,and say that I believe that some people will 
embrace it on the basis that they can constraint the amount of memory PostgreSQL uses on their server as a whole, and
thatincludes caches.  


>> 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?

All I'm trying to say, that whilst you guys focus mostly on single database server installations PostgreSQL has also a
greatuser base that use it as part of a product that is deployed on different sized machines,  
and with same model but different data variation. We don't sell the product to the people and let them take care of it,
butrather sell the service - you would say. But we also don't have a DBA per customer that would look solely 
at the knob tweaking side of things. So my argument here is, that there isn't always a person who would know tables and
databasesby their characteristics and thus be able to tweak settings manually.  
That probably is just a one of many examples where it makes sense, and probably their primary property is that there's
noDBA overlooking whole database and thus being able to tune it.