From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Bad cost estimate with FALSE filter condition
In-reply-to: <55070FC9.4010307@agliodbs.com>
References: <54F119A6.9080106@agliodbs.com>
 <WM!4d936314dc9313889ef2e5e6a4381fd285d187be51c5b5de339e449728769003a8062a9992b607935e468812a6b9b787!@asav-3.01.com>
 <55070FC9.4010307@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
 message dated "Mon, 16 Mar 2015 10:15:53 -0700"
Date: Mon, 16 Mar 2015 14:26:55 -0400
Message-ID: <4345.1426530415@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Josh Berkus <josh@agliodbs.com> writes:
> So ... should I assume my diagnosis is correct?  Haven't heard any other
> suggestions.

I don't see any reason to think this is worth worrying about, or worth
spending planner cycles on to produce a cosmetically nicer cost estimate.
One-time filters always apply at the top plan level so they're unlikely
to change any planner choices.  Moreover, for any case other than the
not-terribly-interesting constant FALSE case, we're better off assuming
that the filter condition will be true (and so there's nothing to adjust).

			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