Re: LEFT JOINs not optimized away when not needed

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: LEFT JOINs not optimized away when not needed
Дата
Msg-id 2517.1404855600@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: LEFT JOINs not optimized away when not needed  (Moshe Jacobson <moshe@neadwerx.com>)
Ответы Re: LEFT JOINs not optimized away when not needed  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-bugs
Moshe Jacobson <moshe@neadwerx.com> writes:
> On Tue, Jul 8, 2014 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No.  There is nothing about GROUP BY in the join removal logic.

> OK. Thank you. Is this something that would make sense to add?

Dunno.  I don't recall any previous requests for such a thing, so I'd not
be inclined to add it unless it can be done very cheaply (in terms of both
code and runtime).  However, it seems like that might possibly be the
case, if someone wanted to pursue making a patch.  The existing logic
to check for "no references above the join" would serve fine to exclude
grouping by the inner relation, so it might only be necessary to check
that the query has GROUP BY/DISTINCT at all (and, I guess, no aggregates
or window functions).  Or possibly I'm missing something.

> More importantly, do you have any suggestions on how we can improve the
> speed of our views when only a couple of columns are selected from them?

Well, I'd stay away from twenty-seven-way joins if I were you :-(.
That's a recipe for pain.  Perhaps denormalizing your schema a bit would
help there.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: gregburek@heroku.com
Дата:
Сообщение: BUG #10911: pg_upgrade appears to lose the transaction id epoch
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #10911: pg_upgrade appears to lose the transaction id epoch