Re: Optimizer hook - Mailing list pgsql-patches

From Tom Lane
Subject Re: Optimizer hook
Date
Msg-id 9710.1190767674@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimizer hook  (Julius Stroffek <Julius.Stroffek@Sun.COM>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Configure template change to use SysV Semaphors on darwin
Next
From: Tom Lane
Date:
Subject: Re: Warning is adjusted of pgbench.