Re: Pre-allocated free space for row updating (like PCTFREE)
От | Jim C. Nasby |
---|---|
Тема | Re: Pre-allocated free space for row updating (like PCTFREE) |
Дата | |
Msg-id | 20050823194546.GP43820@pervasive.com обсуждение исходный текст |
Ответ на | Re: Pre-allocated free space for row updating (like PCTFREE) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Aug 22, 2005 at 10:18:25PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > ... But I agree with Satoshi; if there are > > people who will benefit from this option (which doesn't hurt those who > > choose not to use it), why not put it in? > > Because there's no such thing as a free lunch. Every option we support > costs us in initial implementation time, documentation effort, and > ongoing maintenance. Plus it confuses users who don't know what to do > with it. (Note Josh's nearby lobbying to remove some GUC parameters. > While I opposed him on that particular item, I sympathize with his > point in general.) > > Oracle's approach of "offer every knob you can think of" is not one > that I care to emulate. We have to strike a balance between flexibility > and not having a database that's too complex to administer for anyone > except an expert. The problem is that unless you're going to put a lot of AI in the database[1] (something Oracle is now doing...), you're going to end up limiting yourself. As the PostgreSQL code continues to improve performance-wise, we're going to run into more and more situations where the way to get more performance means adding more tunables. Look at the knobs that have been added for bgwriter and delayed vacuum for example. These were added because the code had gotten to a point where the problems they solve had become bigger and bigger bottlenecks. I know there's hope that eventually these can be turned into simple 1-10 knobs or something, but I'm doubtful that something that simple will suffice for all situations. I do understand the issue of having 100s of knobs, though. I don't think we should go adding knobs willy-nilly (Josh made the good point that there's currently no testing to validate the usefullness of this free space knob, for example). But I also think that the way to control 'knob-bloat' isn't to do everything possible not to add knobs, but to look at how to limit their exposure to people who don't need to know about them. For example, there's less than a half dozen knobs that people always ask about when people post performance questions: shared_buffers, work_mem, effective_cache_size, etc. These are knobs that almost every user needs to know about. Call them 'level 1' knobs. Level 2 might be things like vacuum_cost_delay, maintenance_work_mem, max_fsm_pages, and max_connections. And so on. By grouping in this fashion we can limit exposure to things that most users won't need to mess with, but give users who have need to change these things the ability to do so. [1]: I'm all in favor of making things self-tuning wherever possible, but that's generally a lot more work than just exposing a GUC, so I suspect it will be some time before we get to that point. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461
В списке pgsql-hackers по дате отправления: