On 2014-05-11 12:47:21 -0400, Tom Lane wrote: > Another idea is that the main reason we do things like this is the > assumption that for UPDATE, ModifyTable receives complete new rows > that only need to be pushed back into the table (and hence have > to already match the rowtype of the specific child table). What if > we got rid of that and had the incoming tuples just have the target > row identifier (tableoid+TID) and the values for the updated columns? > ModifyTable then would have to visit the old row (something it must > do anyway, NB), pull out the values for the not-to-be-updated columns, > form the final tuple and store it. It could implement this separately > for each child table, with a different mapping of which columns receive > the updates. This eliminates the whole multiple-plan-tree business > at a stroke ... and TBH, it's not immediately obvious that this would > not be as efficient or more so than the way we do UPDATEs today, even > in the single-target-table case. Pumping all those not-updated column > values through the plan tree isn't free. The more I think about it, > the more promising this sounds --- though I confess to being badly > undercaffeinated at the moment, so maybe there's some fatal problem > I'm missing.
Yes, that sounds like a rather good plan. There's probably some fun keeping the executor state straight when switching more frequently than now and we'd probably need some (implicitly?) added type coercions? I also agree, while there probably are some cases where'd be slower, that the majority of cases will be faster. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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