From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Sabino Mullane <greg@turnstep.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Thu, 12 Jun 2008 12:52:26 -0400
Message-ID: <10801.1213289546@sss.pgh.pa.us> (raw)
In-Reply-To: <f64390b17984f84f526285c89f126930@biglumber.com>
References: <f64390b17984f84f526285c89f126930@biglumber.com>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, greg@turnstep.com
Subject: Re: Overhauling GUCS
In-Reply-To: <10801.1213289546@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox