I've applied this patch with revision to put the hook where I thought it
made sense. Attached is a modification of your dummy.c to show use of
the hook. I didn't test it heavily, but I did check that it seemed to
work with either order of calling geqo() and standard_join_search().
Julius Stroffek <[EMAIL PROTECTED]> 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
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.
Later on, we
Julius Stroffek <[EMAIL PROTECTED]> 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 sens
Well, It seems that I probably do not understand something quite well or
my explanation
is not clear. There is some example code of my idea in the attachment.
There is a function jos_search which has nearly the same code as
make_rel_from_joinlist.
The example tries geqo first and then the regul
Julius Stroffek <[EMAIL PROTECTED]> 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 subpr
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
hav
Julius Stroffek <[EMAIL PROTECTED]> 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'
I rewrote a patch a bit.
I made function make_one_rel_by_joins also non-static,
so that the optimizer in plugin can reuse the dynamic
optimizer.
I also reorganized the code and put all the changes
to paths.h and allpaths.c files only. It seems to me more
appropriate that the hook should belong t
Attached is the patch for the optimizer hook as discussed in
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00362.php
The hook declaration and definition to the same places as the planner_hook
is located since the optimizer_hook relates to the part of the planner and
I find it good to ha
10 matches
Mail list logo
