Josh Berkus <josh@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
