"Greg Sabino Mullane" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
