Re: Missed query planner optimization: `n in (select q)` -> `n in (q)`

On Sun, Jun 12, 2022 at 2:47 PM Josh <postgres(at)sirjosh3917(dot)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.

https://commitfest.postgresql.org/