On Fri, 2 Jan 2026 at 04:30, Jacob Jackson <[email protected]> wrote: > The current memoization cost calculation method often results in memoize > nodes being added even when they are useless due to the outer side of the > join being guaranteed unique due to constraints, increasing overhead > unnecessarily. To try to prevent this, I am exploring methods to check > whether the outer side of the join is guaranteed unique before adding memoize > nodes. The simplest method I have found thus far is to use > innerrel_is_unique, passing in the outer relation where the inner relation > normally would be. This appears to work (although it is logically different > from the other uses of innerrel_is_unique), and adds negligible overhead for > simple joins because it can often reuse cached values from other potential > join orders.
Do you have an example case of this happening? Ideally, the code that should disfavour Memoize for this case is estimate_num_groups() as called in cost_memoize_rescan() by returning that there's 1 group per input row. I guess that's not happening for this case? Why? David
