Re: Optimizer hook

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


> 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
> appropriate.
>
I completely agree and I have renamed the hook.

The new version V3 of the patch is attached.

Thanks for the comments.

Regards

Julius Stroffek

Attachment Content-Type Size
optimizer_hookV3.patch text/x-patch 3.9 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-09-25 18:22:13 Re: PL/TCL Patch to prevent postgres from becoming multithreaded
Previous Message Gregory Stark 2007-09-25 14:56:47 Re: [HACKERS] 'Waiting on lock'