New results for GEQO threshold

After Bruce's fine piece of detective work in finding a bogus keylist
comparison routine, the Postgres optimizer runs a *lot* faster than
before.

>> We have to bump the default value of GEQO threshold up again...
>> it's way too low now...

> Yes.  I need to know what value to set it at.  Do you have some way
> to test that.

I ran some variants of Charles Hornberger's multiway join that started
the whole discussion.  Run times (with profiling on, but that shouldn't
affect the ratios much) now look like

GEQO off            # Indexes available

# Tables        0    12    13    14    15    16

7            1.6    2.0
8            3.6    4.5    4.3
9            10.7    12.3        12.3
10            51.2    55.0            54.2
11            224.4    227.6                213.9

(For reference, the comparable run time for the 7t/12i case was 2630 sec
before Bruce fixed it!  It's not every day that you see a 1300:1 speedup
from changing a couple lines of code...)

As you can see, the number of indexes is no longer a significant factor
in the optimizer's runtime.  I therefore recommend that we revert the
GEQO threshold computation back to the way it was: just use the number
of tables involved.  Simple, quick, easy to understand.

The next question is what the default GEQO threshold value ought to be.
I ran the same tests with and without GEQO; with GEQO on, the runtimes
look like

GEQO on                # Indexes available

# Tables        0    12    13    14    15    16

7            9.4    12.3
8            17.8    22.8    23.1
9            45.9    61.9        59.6
10            58.5    74.9            72.9
11            71.6    79.3                77.9

So, assuming this is a reasonably representative case, it looks like
GEQO should kick in at a threshold of 11 tables.
        regards, tom lane