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 more drastic steps that would have to be 
and I believe that Microsoft engineers had to take them. Steps back. For 
instance, if there is an issue with inability to find 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 that includes caches. 

>> In my current work place/camp we have many deployments of the same system, 
>> over different types of machines, each with different 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 little tweaking 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 installations over 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 great user 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, but rather 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 databases by 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 no DBA overlooking whole database and 
thus being able to tune it. 

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to