Re: Increase value of OUTER_VAR

From: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Increase value of OUTER_VAR
Date: 2021-04-08 05:24:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 4/8/21 8:13 AM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>>> Can we move forward with this?
>> We could just push the change and see what happens. But I was thinking
>> more in terms of doing that early in the v15 cycle. I remain skeptical
>> that we need a near-term fix.
> To make sure we don't forget, I added an entry to the next CF for this.
Thanks for your efforts.

I tried to dive deeper: replace ROWID_VAR with -4 and explicitly change
types of varnos in the description of functions that can only work with
special varnos.
Use cases of OUTER_VAR looks simple (i guess). Use cases of INNER_VAR is
more complex because of the map_variable_attnos(). It is needed to
analyze how negative value of INNER_VAR can affect on this function.

INDEX_VAR causes potential problem:
in ExecInitForeignScan() and ExecInitForeignScan() we do
tlistvarno = INDEX_VAR;

here tlistvarno has non-negative type.

ROWID_VAR caused two problems in the check-world tests:
if (var->varno < root->simple_rel_array_size)
RelOptInfo *rel = root->simple_rel_array[var->varno];


if (!bms_is_member(var->varno, root->curOuterRels))

I skipped this problems to see other weak points, but check-world
couldn't find another.

Andrey Lepikhov
Postgres Professional

Attachment Content-Type Size
0001-remove-64k-rangetable-limit-wip.patch text/x-patch 8.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-08 05:27:59 Re: SQL-standard function body
Previous Message Alvaro Herrera 2021-04-08 05:20:39 pgsql: autovacuum: handle analyze for partitioned tables