Re: Checking join outer relation uniqueness to prevent unnecessary memoization - Mailing list pgsql-hackers

From Jacob Jackson
Subject Re: Checking join outer relation uniqueness to prevent unnecessary memoization
Date
Msg-id CAAiQw3z0K15z_Ojuoe6dh8NyG=GZR-t+UBvTWzoZ-6EDj-L-Fw@mail.gmail.com
Whole thread Raw
In response to Re: Checking join outer relation uniqueness to prevent unnecessary memoization  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Checking join outer relation uniqueness to prevent unnecessary memoization
List pgsql-hackers
On Sun, Jan 4, 2026 at 6:09 PM David Rowley <dgrowleyml@gmail.com> wrote:
> For a fix, I suppose has_unique_index() could be expanded to find a
> unique index which mentions the particular Var and ensures that all
> other columns that exist in the index have EquivalenceClasses with an
> ec_has_const, but that would make that function much more expensive
> than it is today and it still wouldn't cover cases where there is
> another parameter in the Memoize lookup that matches to one of the
> other unique index's columns. That makes me think that the UniqueKey
> stuff might be the solution to these problems, as we'd easily be able
> to determine which unique properties hold true at any level of the
> join. That's a very complex patch, however.

Where can I find the past work on UniqueKey? Nothing turned up in the
git history.

Thanks!
Jacob



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reject Foreign Tables from MIN/MAX indexscan Optimization?
Next
From: Jacob Jackson
Date:
Subject: Re: Proposal: Add a UNIQUE NOT ENFORCED constraint