Re: Missed query planner optimization: `n in (select q)` -> `n in (q)` - Mailing list pgsql-performance

From David G. Johnston
Subject Re: Missed query planner optimization: `n in (select q)` -> `n in (q)`
Date
Msg-id CAKFQuwb49d78mnp7uyJPeX-FiPK9saCG8bqKZP90kryoAuky5A@mail.gmail.com
Whole thread Raw
In response to Missed query planner optimization: `n in (select q)` -> `n in (q)`  ("Josh" <postgres@sirjosh3917.com>)
List pgsql-performance
On Sun, Jun 12, 2022 at 2:47 PM Josh <postgres@sirjosh3917.com> wrote:

This was only possible because I was dealing with arrays though, and an operation such as `in (select unnest...)` can be easily converted to `= any(...)`. However for the general case,

In the general case you don't have subqueries inside join conditions.
 
I believe an optimization in this area may provide benefit as there may exist a circumstance that does not have an alternative to a sub-query select (`= any()` was my alternative)

I think we'd want a concrete example of a non-poorly written query (or at least a poorly written one that, say, is generated by a framework, not just inexperienced human SQL writers) before we'd want to even entertain spending time on something like this.
 
- Is this an issue that should be fixed?

Probably not worth the effort.

I'm fascinated by the work y'all do, and submitting a patch to Postgres that makes it into production would make my week.


Maybe you'll find almost as much good is done helping others get their patches committed.  There are many in need of reviewers.



pgsql-performance by date:

Previous
From: "Josh"
Date:
Subject: Missed query planner optimization: `n in (select q)` -> `n in (q)`
Next
From: "James Pang (chaolpan)"
Date:
Subject: reindex option for tuning load large data