| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Checking join outer relation uniqueness to prevent unnecessary memoization |
| Date: | 2026-01-03 01:44:59 |
| Message-ID: | CAApHDvpEziKD4uXOm4ySe7UKZiy4dSeH0Eo+K_O-M-dyYmGUUw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2 Jan 2026 at 04:30, Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2026-01-03 01:54:59 | Re: Use Postgres as meson wrap subproject |
| Previous Message | Tatsuo Ishii | 2026-01-03 01:04:54 | Re: Row pattern recognition |