Peter Geoghegan <pe...@2ndquadrant.com> writes: > ISTM if '=' was really a mere equivalency operator, we'd only every > check (a < b && b < a) in the btree code.
You're not really making a lot of sense here, or at least I'm not grasping the distinction you want to draw. btree indexes (and sorting in general) require the trichotomy law to hold, so what you say above is tautological. The only reason we test "a = b" and not "a < b || a > b" is that the latter is at least twice as expensive to evaluate. The last section of src/backend/access/nbtree/README has some notes that you might find relevant. > Simple question: if you were to just remove the strcmp tie-breaker for > strcoll() in varstr_cmp(), but not touch anything else, would Postgres > exhibit objectively incorrect behaviour? Yes, it would, and did, before we put that in; see the archives for the discussions that led up to the patch you mentioned earlier. > So, I may have lost sight of why I starting on about equivalency, > which is that it sure would be nice if we could use strxfrm to prepare > strings for sorting, which looks to be a fairly significant win. We could still do that as long as we were willing to store the original strings as well as the strxfrm output. Given the memory bloat already implied by strxfrm, I don't think that's necessarily ridiculous on its face --- it just makes the bar a bit higher for whether this is a win. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers