I got an example where paths for plain rel require param_info i.e. plain rel scans require to take care of the lateral references. Here's the example from PG regression
explain verbose select v.* from (int8_tbl x left join (select q1,(select coalesce(q2,0)) q2 from int8_tbl) y on x.q2 = y.q1) left join int4_tbl z on z.f1 = x.q2, lateral (select x.q1,y.q1 from dual union all select x.q2,y.q2 from dual) v(vx,vy); There is note in create_scan_plan(), which says, 324 * If it's a parameterized otherrel, there might be lateral references 325 * in the tlist, which need to be replaced with Params. This cannot 326 * happen for regular baserels, though. Note use_physical_tlist() 327 * always fails for otherrels, so we don't need to check this above. 328 */ Although it doesn't say why this can not happen for regular baserels. So, we do have a testcase which tests this code path as well. On Mon, Oct 28, 2013 at 12:30 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > No adding OFFSET there too didn't give the expected result. The lateral > was handled in subquery and passed as param to the underlying table scan. > > I am particularly interested in tables (unlike functions or subqueries) > since, the table scans are shipped to the datanodes and I wanted to test > the effect of lateral in such cases. OTH, functions involving access to the > tables or subqueries are initiated on the coordinators, where lateral gets > executed in the same way as PostgreSQL. > > If it's so hard to come up with an example query which would cause > lateral_relids to be set in RelOptInfo of a table, then it's very likely > that relevant code is untested in PostgreSQL. > > > On Fri, Oct 25, 2013 at 7:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >> > In order to test various cases of LATERAL join in Postgres-XC, I am >> trying >> > to find a query where RelOptInof->lateral_relids would get set for plain >> > base relations. >> >> I think you need a lateral reference in a function or VALUES FROM-item. >> As you say, plain sub-selects are likely to get flattened. (Possibly >> if you stuck in a flattening fence such as OFFSET 0, you could get the >> case to happen with a sub-select FROM item, but I'm too lazy to check.) >> >> regards, tom lane >> > > > > -- > Best Wishes, > Ashutosh Bapat > EnterpriseDB Corporation > The Postgres Database Company > -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
