Julius Stroffek <Julius.Stroffek@Sun.COM> writes: > I rewrote a patch a bit. 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? I do not see the value of duplicating the joinlist-expansion logic, which is what you're going to have to do if you use a hook that replaces make_rel_from_joinlist. The only things you could do differently than it does would be (1) be smarter about full outer joins, which was not part of the agenda that I heard of, or (2) willfully disregard the user's from_collapse_limit and join_collapse_limit settings, which doesn't seem like an amazingly good idea either. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Julius Stroffek <Julius.Stroffek@Sun.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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Julius Stroffek <Julius.Stroffek@Sun.COM> writes: > Parts of the result path might be found by geqo and parts of it by > regular algorithm. Why would you care? Seems like forcing that to not happen is actively making it stupider. > If there is no way of how to make the code work then it makes no sense > to put the hook to the place I am proposing. It works for me, but I have > not tested that very well yet. If I would swap calls to geqo > and make_one_rel_by_joins it will not work. Therefore there might be > an issue I do not know about yet. Well, I can see one likely problem: list_copy is a shallow copy and thus doesn't ensure that the second set of functions sees the same input data structures as the first. I know that geqo has to go through some special pushups to perform multiple invocations of the base planner, and I suspect you need that here too. Look at geqo_eval(). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

Julius Stroffek <Julius.Stroffek@Sun.COM> writes: >> Why would you care? Seems like forcing that to not happen is actively >> making it stupider. >> > To better compare the algorithms and possibly not for final solution at > the beginning. If we would implement 10 algorithms and want to pickup > just 3 best ones to be used and throw 7 away. Well, you could in any case force the same decision to be made in every invocation, for example by driving it off a GUC variable. The idea you have here seems to be "it'll be the same choice in every sub-problem, only we won't know which one afterwards", which doesn't seem at all helpful for planner testing purposes. > Yes, the example in dummy.c is really stupider, but it could be done > in more clever way. I think dummy.c kinda proves my point: more than half the code is accomplishing nothing except to duplicate the behavior of make_rel_from_joinlist. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings