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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers