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)

There is note in create_scan_plan(), which says,
 324          * If it's a parameterized otherrel, there might be lateral
 325          * in the tlist, which need to be replaced with Params.  This
 326          * happen for regular baserels, though.  Note
 327          * always fails for otherrels, so we don't need to check this
 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

Reply via email to