Skip site navigation (1) Skip section navigation (2)

Re: PROPOSAL: geqo improvement

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "marcin mank" <marcin(dot)mank(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PROPOSAL: geqo improvement
Date: 2009-01-05 02:06:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2009/1/4 marcin mank <marcin(dot)mank(at)gmail(dot)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.


In response to


pgsql-hackers by date

Next:From: ITAGAKI TakahiroDate: 2009-01-05 02:06:43
Subject: Many "loaded library" logs by preload libraries
Previous:From: marcin mankDate: 2009-01-05 01:55:11
Subject: PROPOSAL: geqo improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group