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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Missed query planner optimization: `n in (select q)` -> `n in (q)`
Дата
Msg-id CAKFQuwb49d78mnp7uyJPeX-FiPK9saCG8bqKZP90kryoAuky5A@mail.gmail.com
обсуждение исходный текст
Ответ на Missed query planner optimization: `n in (select q)` -> `n in (q)`  ("Josh" <postgres@sirjosh3917.com>)
Список 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 по дате отправления:

Предыдущее
От: "Josh"
Дата:
Сообщение: Missed query planner optimization: `n in (select q)` -> `n in (q)`
Следующее
От: "James Pang (chaolpan)"
Дата:
Сообщение: reindex option for tuning load large data