Re: [HACKERS] and again ... optimizer

Martin S. Utesch wrote:
>
> Vadim wrote:
>
> > Martin, I see that geqo_eval.c:gimme_tree() also calls compute_rel_size()
> > while compute_joinrel_size() already called by
> > geqo_paths.c:geqo_rel_paths(). After commenting out compute_rel_size()
> > GEQO returns good plan too. But I didn't change CVS...
> > Your decision ?
>
> I trust your decision. Do it.

Ok.

> What about *compute_rel_width*?

All right here.

>
> Please also have a look at the following...
>
> 1.) In case of *standard PG optimizer* the following would be relevant:
>     joinrels.c:init_join_rel->set_joinrel_size
>                               ^^^^^^^^^^^^^^^^(this seems to be a hack)
>     This is the first time the size of a new created joinrel is touched.
>     Is the code o.k.?
>
> 2.) In case of *GEQO* the following would be relevant:
>     geqo_eval.c:init_join_rel->geqo_joinrel_size
>                                ^^^^^^^^^^^^^^^^^which is the same as
>     set_joinrel_size, but it makes log2 of the output if the value
>     rel->size becomes bigger than MAXINT. I encounterd such several
>     times. It's a pity that t'rel size is defined as int, not float so
>     that such hacks are neccessary :-(

I havn't time currently, but you're right - we need in some cleanups here.

Vadim

------------------------------