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 taken 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: http://www.postgresql.org/mailpref/pgsql-hackers
