>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> After digging into it, I find that: Tom> 1. Without ORDER BY, process_equivalence generates an Tom> equivalence class that lists k twice. This is pretty bogus but Tom> it happens to produce the desired results in the example at Tom> hand. (In some other cases you'll get redundant clauses out, Tom> because the eclass machinery isn't expecting this.) Tom> 2. With ORDER BY k, the code first creates a single-element Tom> equivalence class containing k, because it needs that to Tom> represent the desired pathkey. Then, process_equivalence finds Tom> that both sides of the k = k clause are already known to be in Tom> the same eclass, so it concludes that this is redundant Tom> information. I'd found the right place in the code, but I hadn't twigged that the ORDER BY one was being called _first_, so I hadn't spotted the bug yet. Tom> I'm inclined to think that the best solution is to have Tom> process_equivalence just reject any clauses that have equal() Tom> left and right sides, ie, throw them back to be processed as Tom> ordinary non-equivalence clauses. The only case I can think of Tom> where this might be less than ideal is if you have "k = k AND k Tom> = x"; if both operators are strict then the k = k test is indeed Tom> redundant and could be discarded, but it won't be. But it Tom> doesn't seem like that's going to come up enough to be worth Tom> stressing about. If we wanted to be smart about it we'd have to Tom> have two kinds of single-element equivalence classes (one that Tom> implies a k = k check is needed, and one that does not). It Tom> doesn't seem worth the complication. Hmm. Is it ever possible for mergejoinable operators to be non-strict? Does that matter? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
