I've decided to abandon this patch. I have spent too much time looking
at it now.
If anyone is interested in trying to study, I can provide the patches I
came up with, explanations, and references to prior discussion -- feel
free to ask.
My main motivation for this work is to enable a later patch for column
stores. Right now, since columns have monotonically increasing attnums,
it's rather difficult to have columns that are stored elsewhere. My
plan for that now is much more modest, something like adding a constant
10000 to attnums and that would let us identify columns that are outside
the heap -- or something like that. I haven't fully worked it out yet.
Just a few quick notes about this patch: last thing I was doing was mess
with setrefs.c so that Var nodes carry "varphysnum" annotations, which
are set to 0 during initial planner phases, and are turned into the
correct attphysnum (the value extracted from catalogs) so that
TupleDescs constructed from targetlists by ExecTypeFromTL and friends
can have the correct attphysnum too. I think this part works correctly,
with the horrible exception that I had to do a relation_open() in
setrefs.c to get hold of the right attphysnum from a tupledesc obtained
from catalogs. That's not acceptable at all; I think the right way to
do this would be to store a list of numbers earlier (not sure when) and
store it in RelOptInfo or RangeTableEntry; that would be accesible
during setrefs.c.
The other bit I did was modify all the heaptuple.c code so that it could
deal correctly with tupledescs that have attphysnums and attlognum in an
order different from stock attnum. That took some time to get right,
but I think it's also correct now.
One issue I had was finding places that use "attnum" as an index into
the tupledesc "attrs" array. I had to examine all these places and
change them to use a "physattrs" array, which is an array that has been
sorted by physical number. I don't think all the changes are correct,
and I'm not sure that I caught them all.
Anyway it seems to me that this is "mostly there". If somebody is
interested in learning executor code, this project would be damn cool to
get done.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services