Re: Optimizer hook
От | Julius Stroffek |
---|---|
Тема | Re: Optimizer hook |
Дата | |
Msg-id | 46F99C70.50203@sun.com обсуждение исходный текст |
Ответ на | Re: Optimizer hook (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Optimizer hook
Re: Optimizer hook |
Список | pgsql-patches |
> 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 can try to run just the one "very fast" algorithm and depending on the cost decide whether we would run remaining 9 or less or even none. Yes, the example in dummy.c is really stupider, but it could be done in more clever way. > 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(). I'll explore that. Thanks Regards Julius Stroffek
В списке pgsql-patches по дате отправления: