Re: generalizing the planner knobs

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: generalizing the planner knobs
Дата
Msg-id 1133803864.4779.179.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: generalizing the planner knobs  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
[snip]
> 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.
> 

Now this is exactly what I've had in mind... it would be nice to
"fixate" a plan for some of the queries, and let the planner choose the
best for all the rest. I think some other data bases have something like
an "optimizer plan stability" feature, providing "outlines" of query
plan bundles. This is maybe too much, but specifying that for a certain
query I definitely want to use one index and not the other would be
nice...

On another note, it might be interesting to have some kind of "prepare
analyze", where the planner is allowed to go and get some more detailed
estimation from the actual table data based on the hard-coded parameter
values, and produce some more detailed statistics for the parameterized
values so it can then produce hot-shot plans for the actual parameter
values on each execution... I wonder if this makes any sense. This way
we could have some very detailed statistics directly supporting the
queries we actually use. I would call this kind of prepare for the most
used/problematic queries from time to time, and the planner should
decide what statistics it needs to support it and go and get it...

Cheers,
Csaba.





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: generalizing the planner knobs
Следующее
От: Zoltan Boszormenyi
Дата:
Сообщение: Re: SERIAL type feature request