Re: PROPOSAL: geqo improvement - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PROPOSAL: geqo improvement
Date
Msg-id 603c8f070901041806s36715260t3b498ec3c6ff5fe7@mail.gmail.com
Whole thread Raw
In response to PROPOSAL: geqo improvement  ("marcin mank" <marcin.mank@gmail.com>)
Responses Re: PROPOSAL: geqo improvement  ("marcin mank" <marcin.mank@gmail.com>)
List 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 by date:

Previous
From: "marcin mank"
Date:
Subject: PROPOSAL: geqo improvement
Next
From: ITAGAKI Takahiro
Date:
Subject: Many "loaded library" logs by preload libraries