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

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 (view raw or flat)
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

pgsql-patches by date

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

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