Re: Optimizer hook

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julius Stroffek <Julius(dot)Stroffek(at)Sun(dot)COM>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Optimizer hook
Date: 2007-09-25 20:44:57
Message-ID: 27587.1190753097@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Julius Stroffek <Julius(dot)Stroffek(at)Sun(dot)COM> writes:
>> 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.

That would be an entirely different problem, I think. If you want to
replace the *entire* planner, there's already the planner_hook to do that.
If you're just looking to change the join order search method, the place
where GEQO hooks in is the most convenient place for that. It's not
clear to me what would be usefully accomplished by putting the hook
somewhere else; you can't just willy-nilly replace the code for
single-relation path selection, at least not without a whole lot of
changes elsewhere in the planner infrastructure.

My thought was that the reason for this hook to exist was simply to
provide a convenient way to replace only the join search order
algorithm. I'm willing to entertain the thought of other hooks in other
places for other specific purposes, but where you want to put it seems
not well-matched to any problem that would be likely to be solved
without replacing all of the planner.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Julius Stroffek 2007-09-25 22:18:39 Re: Optimizer hook
Previous Message Stefan Kaltenbrunner 2007-09-25 18:22:13 Re: PL/TCL Patch to prevent postgres from becoming multithreaded