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

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: (view raw, whole thread or download thread mbox)
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.


Julius Stroffek

Attachment: optimizer_hookV3.patch
Description: text/x-patch (3.9 KB)

In response to


pgsql-patches by date

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

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