Re: Removing INNER JOINs
От | David Rowley |
---|---|
Тема | Re: Removing INNER JOINs |
Дата | |
Msg-id | CAKJS1f8i4+-Hu5yD9Vhxw1LbQzsVgUVWTPkmHcuGs4eYvk3O_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing INNER JOINs (Jim Finnerty <jfinnert@amazon.com>) |
Список | pgsql-general |
On 12 December 2017 at 02:38, Jim Finnerty <jfinnert@amazon.com> wrote: > If necessary, the planner could also check that the FK constraint is not > DEFERRED, but if there are no volatile functions and the SELECT statement > can't see an inconsistent state created by any other transaction, I think > that just checking for volatile functions and not being inside a DML > transaction would be sufficient. > > A further opportunity would be to apply this to any SELECT statement in a > DML transaction, provided that there was no prior DML statement or statement > containing a volatile function in the same transaction. > > We already have a redundant outer join optimization, and I've implemented > the redundant inner join optimization in two other products before, so > adding the additional logic to support the inner join case(s) sounds > straightforward to me. Can anyone think of any other problem scenarios? You should read over [1]. This was my attempt at doing this over 3 years ago. The thread might save you from going down some of the dead ends that I ended up going down. [1] https://www.postgresql.org/message-id/flat/CAApHDvpCBEfuc5tD=vniepAv0pU5m=q=fOQZcOdMHeei7OQPgQ@mail.gmail.com#CAApHDvpCBEfuc5tD=vniepAv0pU5m=q=fOQZcOdMHeei7OQPgQ@mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-general по дате отправления: