Subject: Re: An incorrect check in get_memoize_path

From: Andrei Lepikhov <[email-masked]>
Date: Mon, 7 Apr 2025 14:54:24 +0200

On 4/7/25 09:50, Richard Guo wrote:
> 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.
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):

#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

---

From: Richard Guo <[email-masked]>
Date: Tue, 8 Apr 2025 15:32:00 +0900

> I think this inequality check has worked in couple with the

Do you mean this check is designed to work in conjunction with the
clause_sides_match_join check in paraminfo_get_equal_hashops?  I would
consider this a very poor design.  The purpose of this check is simply
to verify whether all restriction clauses are parameterized.  I don't
understand why it needs to depend on paraminfo_get_equal_hashops in
such an unexpected way to function correctly.  I can't see any
advantage to this design, other than that it's prone to bugs.
Moreover, in the case where not all restriction clauses are
parameterized, why waste CPU cycles running all the code after the
check only for paraminfo_get_equal_hashops to catch it later?
Additionally, I couldn't find any comments explaining this unusual
behavior, either in the check itself or in paraminfo_get_equal_hashops.

Thanks
Richard