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  (Csaba Nagy <nagy@ecircle-ag.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] snprintf() argument reordering not working
Следующее
От: Csaba Nagy
Дата:
Сообщение: Re: generalizing the planner knobs