> This hook seems very strangely defined to me. Why did you not put the
> hook at the point where the current geqo-vs-regular decision is made?
The reason is that I thought about gaining a control over the algorithm
used to solve individual subproblems in make_rel_from_joinlist. If we would
have a couple of algorithms to be tested we can implement a plugin
using join_order_search_hook which will compare the results of
those algorithms. Doing the same at the place where geqo/regular code is
called might make thinks a bit more difficult.
Later on, we could also implement a code trying to run some "very fast"
algorithm at first (for the master problem and all subproblems) to get
some estimates and decide whether it makes sense to try to find a better
plan in longer time.
> Also, "optimizer_hook" seems nearly content-free as a name for use
> in this area; I see no reason why the particular sub-section of the
> planner we're discussing here has more title to that name than other
> parts. Something like "join_order_search_hook" might be more
I completely agree and I have renamed the hook.
The new version V3 of the patch is attached.
Thanks for the comments.
In response to
pgsql-patches by date
|Next:||From: Stefan Kaltenbrunner||Date: 2007-09-25 18:22:13|
|Subject: Re: PL/TCL Patch to prevent postgres from becoming multithreaded|
|Previous:||From: Gregory Stark||Date: 2007-09-25 14:56:47|
|Subject: Re: [HACKERS] 'Waiting on lock'|