Re: PROPOSAL: geqo improvement

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: PROPOSAL: geqo improvement
Дата
Msg-id 603c8f070901041806s36715260t3b498ec3c6ff5fe7@mail.gmail.com
обсуждение исходный текст
Ответ на PROPOSAL: geqo improvement  ("marcin mank" <marcin.mank@gmail.com>)
Ответы Re: PROPOSAL: geqo improvement  ("marcin mank" <marcin.mank@gmail.com>)
Список pgsql-hackers
2009/1/4 marcin mank <marcin.mank@gmail.com>:
> GEQO would decide that the plan is bad when the calculated cost of the
> plan would exceed the time spent planning so far a fixed number of
> times (100 ? a configurable parameter ?) .
> I think a function infering cost from time spent could be calculated
> from cpu_operator_cost - or is there a better way?

It sounds like you're proposing to compare the time spent planning to
the estimated execution time.  AFAICS, those things are unrelated, so
I'm not sure what you hope to figure out by comparing them.

> An alternative to restarting the search might be just extending it -
> running the main loop of geqo() function longer.  I plan restarting
> because I`m afraid the real reason for getting bad plans could be that
> the algorithm is getting into some local minimum and can`t get out. I
> will explore that more.

It sounds like you may have some concrete queries that suffer from
this problem.  It might be helpful to post the queries and the good
and bad plans.  It may be that the problem can be fixed with some
tuning of the existing parameters.

> If there is agreement to do this, it looks simple enough that I
> volunteer to implement it. Please tell me what is the deadline for
> this to make into 8.4 .

The deadline for the final CommitFest was November 1st, so I think it
is too late for 8.4.

...Robert


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

Предыдущее
От: "marcin mank"
Дата:
Сообщение: PROPOSAL: geqo improvement
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Many "loaded library" logs by preload libraries