Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUMk-00082G-TP for pgsql-performance@arkaria.postgresql.org; Sat, 22 Jun 2013 20:24:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UqUMk-0006c0-C6 for pgsql-performance@arkaria.postgresql.org; Sat, 22 Jun 2013 20:24:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUMj-0006bt-8s for pgsql-performance@postgresql.org; Sat, 22 Jun 2013 20:24:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUMg-0006k0-7m for pgsql-performance@postgresql.org; Sat, 22 Jun 2013 20:24:56 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r5MKOnDj024523; Sat, 22 Jun 2013 16:24:49 -0400 (EDT) From: Tom Lane To: Josh Berkus cc: "pgsql-performance@postgresql.org" Subject: Re: Weird, bad 0.5% selectivity estimate for a column equal to itself In-reply-to: <51C4D1E8.6090602@agliodbs.com> References: <51C4AEE5.8040704@agliodbs.com> <25930.1371850378@sss.pgh.pa.us> <51C4D1E8.6090602@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Fri, 21 Jun 2013 15:21:28 -0700" Date: Sat, 22 Jun 2013 16:24:48 -0400 Message-ID: <24522.1371932688@sss.pgh.pa.us> X-Pg-Spam-Score: -3.2 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Josh Berkus writes: > On 06/21/2013 02:32 PM, Tom Lane wrote: >> See DEFAULT_EQ_SEL. > Why is it using that? We have statistics on the column. What reason > would it have for using a default estimate? The stats are generally consulted for "Var Op Constant" scenarios. It doesn't know what to do with "Var Op Var" cases that aren't joins. As long as we lack cross-column-correlation stats I doubt it'd be very helpful to try to derive a stats-based number for such cases. Of course, "X = X" is a special case, but ... >> But why exactly do you care? Surely it's a stupid >> query and you should fix it. > (b) that query is also auto-generated by external software, so "just fix > it" isn't as easy as it sounds. Personally, I'll bet lunch that that external software is outright broken, ie it probably thinks "X = X" is constant true and they found they could save two lines of code and a few machine cycles by emitting that rather than not emitting anything. Of course, the amount of parsing/planning time wasted in dealing with the useless-and-incorrect clause exceeds what was saved by multiple orders of magnitude, but hey it was easy. It wouldn't take too much new code to get the planner to replace "X = X" with "X IS NOT NULL", but I think we're probably fixing the wrong piece of software if we do. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance