Re: Overhauling GUCS

"Greg Sabino Mullane" <greg@turnstep.com> writes:
> The orders of magnitude speed up of certain queries when the d_s_t goes
> above 98 is what spawned my original thread proposing a change to 100:
> http://markmail.org/message/tun3a3juxlsyjbsw

That was a pretty special case (LIKE/regex estimation), and we've since
eliminated the threshold change in the LIKE/regex estimates anyway, so
there's no longer any reason to pick 100 as opposed to any other number.
So we're still back at "what's a good value and why?".

> Frankly, I'd be shocked if there is any significant difference and all
> compared to the actual query run time.

I'm still concerned about the fact that eqjoinsel() is O(N^2).  Show me
some measurements demonstrating that a deep nest of equijoins doesn't
get noticeably more expensive to plan --- preferably on a datatype with
an expensive equality operator, eg numeric --- and I'm on board.
        regards, tom lane