On Fri, May 11, 2012 at 5:52 PM, Antonin Houska <antonin.hou...@gmail.com> wrote: > Hello, > following this short discussion > http://archives.postgresql.org/message-id/4f5aa202.9020...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
