On Fri, May 11, 2012 at 5:52 PM, Antonin Houska
<antonin.houska@gmail.com> wrote:
> Hello,
> following this short discussion
> http://archives.postgresql.org/message-id/4F5AA202.9020906@gmail.com
> I gave it one more try and hacked the optimizer so that function can become
> an inner relation in NL join, parametrized with values from the outer
> relation.
>
> I tried to explain my thoughts in comments. Other than that:
>
> 1. I haven't tried to use SpecialJoinInfo to constrain join order. Even if
> the order matters in query like
> SELECT * from a, func(a.i)
> it's still inner join by nature. SpecialJoinInfo is used for INNER join
> rarely, but never stored in PlannerInfo. Doing so only for these lateral
> functions would be rather disruptive.
>
> 2. Simple SQL function (i.e. one that gets pulled-up into the main query) is
> a special case. The query that results from such a pull-up no longer
> contains any function (and thus is not affected by this patch) but such
> cases need to be newly taken into account and examined / tested (the patch
> unblocks them at parsing stage too).
>
> 3. There might be some open questions about SQL conformance.
>
> I've spent quite a while looking into the optimizer code and after all I was
> surprised that it didn't require that many changes. At least to make few
> simple examples work. Do I ignore any important fact(s) ?
This implementation looks different than I'd expect: I would have
thought that it would work by generating paths with param_info set to
the appropriate set of rels to provide the necessary values, rather
than inventing its own mechanism for forcing a nestloop.
Also, I think we will want something that implements the LATERAL()
syntax, rather than just removing the prohibition on lateral
references.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company