Re: generalizing the planner knobs
От | Greg Stark |
---|---|
Тема | Re: generalizing the planner knobs |
Дата | |
Msg-id | 87slt7bh8u.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: generalizing the planner knobs (Hans-Juergen Schoenig <postgres@cybertec.at>) |
Ответы |
Re: generalizing the planner knobs
|
Список | pgsql-hackers |
Hans-Juergen Schoenig <postgres@cybertec.at> writes: > I think I know what Greg is trying to say: I think in this plan stability > does not mean that the plan has to be completely fixed - usually it is all > about indexing. "Usually" problems occur because someone hasn't run analyze at all. That's not what I'm talking about. I'm talking about a large mature system where the DBA has everything tuned and adjusted properly and just wants to get a good night's sleep, confident that the nightly analyze isn't going to suddenly change the performance of existing queries. > Adding hints to some comments or to the statement itself is not a good > solution as well. This is why I proposed a table or some flag telling the > planner what to favour (= always use a certain index). So the basic idea is > not to turn index of in general but to have the chance to do it on a per index > basis. I guess this would not be to complex to implement and it solves 90% of > all problems without having to hide some information inside comments (which is > no good at all). I disagree that this is a reasonable solution. I want to be sure my existing queries keep using the plans they've been using until I allow them to change. I don't want to sit down and type "select count(*) from users" and have it not work correctly (ie, use a sequential scan) because the system is so single mindedly tuned for the OLTP application. -- greg
В списке pgsql-hackers по дате отправления: