Re: pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks - Mailing list pgsql-committers

From Bruce Momjian
Subject Re: pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
Date
Msg-id 200903280207.n2S27QN13789@momjian.us
Whole thread Raw
In response to pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks  (tgl@postgresql.org (Tom Lane))
List pgsql-committers
Tom, you mentioned this should be a TODO item.  Do we put it on our main
TODO, and if so, in what section?

---------------------------------------------------------------------------

Tom Lane wrote:
> Log Message:
> -----------
> Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
> the ON clause of an outer join.  Doing so is semantically correct but results
> in de-optimizing queries that were structured to take advantage of the sublink
> style of execution, as seen in recent complaint from Kevin Grittner.  Since
> the user can get the other behavior by reorganizing his query, having the
> flattening happen automatically is just a convenience, and that doesn't
> justify breaking existing applications.  Eventually it would be nice to
> re-enable this, but that seems to require a significantly different approach
> to outer joins in the executor.
>
> Modified Files:
> --------------
>     pgsql/src/backend/optimizer/prep:
>         prepjointree.c (r1.63 -> r1.64)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepjointree.c?r1=1.63&r2=1.64)
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-committers by date:

Previous
From: bmomjian@pgfoundry.org (User Bmomjian)
Date:
Subject: pg-migrator - src: Remove restore of oid counter because it might
Next
From: momjian@postgresql.org (Bruce Momjian)
Date:
Subject: pgsql: Better document that SET ROLE does not uset ALTER ROLE SET