On 4/7/25 09:50, Richard Guo wrote:
At least, this code looks more simple to understand, more 'armored' and worth to change. At the same time I think term 'Incorrect' is not good unless you show an example where data returned is not consistent to the expected. I think this inequality check has worked in couple with the get_equal_hashops. I think it may be pushed as is. But it worth to discover the get_equal_hashops more deeply. Discovering your idea I wrote an example (see attachment) which (with commented clause_sides_match_join) provides an incorrect Memoize - that's why I ended up with support of your change even when you can't show any buggy behaviour. But I've got an assertion that is different from the error I expected to see (error on single_row mode):Consider the join to t3. It is a unique join, and not all of its restriction clauses are parameterized. Despite this, the check still passes.
#0 0x00005583c45532ce in CheckVarSlotCompatibility #1 0x00005583c4553244 in CheckExprStillValid #2 0x00005583c45530ea in ExecInterpExprStillValid #3 0x00005583c45a245c in ExecEvalExpr #4 0x00005583c45a3985 in prepare_probe_slot #5 0x00005583c45a3e52 in cache_lookup #6 0x00005583c45a4313 in ExecMemoize It looks strange. -- regards, Andrei Lepikhov
example.sql
Description: application/sql
