apprelids

I'm a bit confused by what the 'apprelids' field in the Append and
MergeAppend nodes is supposed to be doing. Its contents seem to be ...
kinda random.

1. If a (Merge)Append is generated by partition expansion, then
apprelids ends up being the RTI generated for the parent table. If you
do a partitionwise join, apprelids for the resulting Append node ends
up containing all the RTIs for all the parent tables involved in said
partitionwise join. So far, so good.

2. If a (Merge)Append is generated by a UNION ALL, then apprelids ends
up being an RTI artificially created to represent the root of the
setop tree. That also seems more or less reasonable, except that this
interpretation wins over the previous interpretation even when the
UNION ALL is SELECT * FROM some_partitioned_table UNION ALL SELECT *
FROM some_partitioned_table. In that case, the RTIs generated by
some_partitioned_table seem to be unreferenced in the plan tree. The
Append relation gets tagged with RTI 1 (for the setop) and its
children are not Append nodes but direct scans of the children of
some_partitioned_table and so carry the RTIs generated by partition
expansion.

3. In some other cases, such as partitionwise aggregate, apprelids
ends up empty.

What I don't understand is: how are we managing to get any use out of
a field that is overloaded in this way? You can't for example rely on
it to lock anything, because of the fact that setop flattening can
cause the RTIs of parent tables involved in inheritance expansion to
end up not being included; the case where it's empty because of
partitionwise aggregate seems like a problem for anything like this,
too.

I thought maybe it would be used for something by EXPLAIN, and indeed
ExplainPreScanNode() pushes the contents of apprelids into rels_used,
but there are no other references to apprelids in explain*.c. It is
referenced by resolve_special_varno() in ruleutils.c which might be
relevant, but I don't understand what's happening there. It's
certainly not the case that the name of the corresponding relation(s)
is/are displayed anywhere on the node itself, as in other cases like
when ExecPreScanNode() adds scanrelid from a scan node to *rels_used,
e.g. "Seq Scan on whatever".

I also thought it might be used somehow by partition pruning, and
indeed it gets passed to ExecInitPartitionExecPruning() as 'relids',
but that seems to just be used as a cross-check against planner
errors. I haven't really traced through all of the logic here yet,
though, so maybe it's used for something else deeper in the code.

I can spend more time looking into this if necessary, but I'm
wondering if anyone has any insight to share. I'm pretty sure this
field does something, but (a) I don't really understand what that
thing is and (b) I have trouble understanding how it can be anything
fundamental given the odd way that the field seems to be overloaded.

Any help appreciated.

Thanks,

--
Robert Haas
EDB: http://www.enterprisedb.com