Re: scenario with a slow query
| От | Tom Lane |
|---|---|
| Тема | Re: scenario with a slow query |
| Дата | |
| Msg-id | 25162.1326910101@sss.pgh.pa.us обсуждение |
| Ответ на | scenario with a slow query (Volodymyr Kostyrko <c.kworr@gmail.com>) |
| Ответы |
Transaction ID wraparound, Oracle style
Re: scenario with a slow query |
| Список | pgsql-general |
Volodymyr Kostyrko <c.kworr@gmail.com> writes:
> Maybe I'm missing something but I have found a case when planner is
> unoptimal.
The planner knows next to nothing about optimizing FULL JOIN, and
I would not recommend holding your breath waiting for it to get better
about that, because there's basically no demand for the work that'd
be involved. I'd suggest refactoring this query instead. A nest of
full joins seems like a rather unintuitive way to get the result
anyway ...
regards, tom lane
В списке pgsql-general по дате отправления: