| From: | Feike Steenbergen <feikesteenbergen(at)gmail(dot)com> |
|---|---|
| To: | Lea Führer <lea(at)codecat(dot)at> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: MERGE INTO... WHEN NOT MATCHED BY SOURCE index usage |
| Date: | 2026-02-25 16:35:34 |
| Message-ID: | CAK_s-G3MKiLACGZqdrg7ZeGYjWPJGXJUSq5erhb4GsXHHy-SuA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 23 Feb 2026 at 15:19, Lea Führer <lea(at)codecat(dot)at> wrote:
> It seems to me like one very common use-case, and one I have bumped into
> often, is to update a n:m resolution table, like this for example:
Something similar was previously discussed in January 2025 as well:
To summarize:
Tom Lane wrote:
> I may not have fully wrapped my head around this example, but I think
> that the fact that "t.device_id = $1" appears in both the ON condition
> and the WHEN NOT MATCHED BY SOURCE condition means that only t rows
> meeting that condition are of interest, so that in principle we could
> optimize by pushing that down to the scan of t. But as you can see,
> we don't. Not sure if this pattern is common enough to be worth
> trying to implement such an optimization.
So at least there's 1 more who uses this pattern!
Kind regards
Feike
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Attila Soki | 2026-02-26 16:15:52 | Re: unstable query plan on pg 16,17,18 |
| Previous Message | Andrei Lepikhov | 2026-02-24 19:20:29 | Re: unstable query plan on pg 16,17,18 |