From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Overhauling GUCS |
Date: | 2008-06-12 16:52:26 |
Message-ID: | 10801.1213289546@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Greg Sabino Mullane" <greg(at)turnstep(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-12 17:08:19 | Re: Options for protocol level cursors |
Previous Message | James William Pye | 2008-06-12 16:26:07 | Options for protocol level cursors |