Andrei Lepikhov <a.lepik...@postgrespro.ru> writes: > On 9/4/2024 09:12, Tom Lane wrote: >> I have another one that I'm not terribly happy about: >> Author: Alexander Korotkov <akorot...@postgresql.org> >> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300 >> Transform OR clauses to ANY expression
>> * What the medical community would call off-label usage of >> query jumbling. I'm not sure this is even correct as-used, >> and for sure it's using that code for something never intended. >> Nor is the added code adequately (as in, at all) documented. > I agree with documentation and disagree with critics on the expression > jumbling. It was introduced in the core. Why don't we allow it to be > used to speed up machinery with some hashing? I would back up from that a good deal: why do we need to hash here in the first place? There's no evidence I'm aware of that it's needful from a performance standpoint. >> * I really, really dislike jamming this logic into prepqual.c, >> where it has no business being. I note that it was shoved >> into process_duplicate_ors without even the courtesy of >> expanding the header comment: > Yeah, I preferred to do it in parse_expr.c with the assumption of some > 'minimal' or 'canonical' tree form. That seems quite the wrong direction to me. AFAICS, the argument for making this transformation depends on being able to convert to an indexscan condition, so I would try to apply it even later, when we have a set of restriction conditions to apply to a particular baserel. (This would weaken the argument that we need hashing rather than naive equal() tests even further, I think.) Applying the transform to join quals seems unlikely to be a win. regards, tom lane