On Wed, 2010-08-11 at 22:09 +0800, Boxuan Zhai wrote: > One more thing I want to point out is that, the INSERT is also an > inheritable action in MERGE. For a plain INSERT command, all the > inserted tuples are put in the target table ONLY. It is easy to > understand. We don't want to duplicate all the new tuples in all > children tables. However, in MERGE command, an INSERT action is > activated by the tuples fitting its matching conditions. The main plan > of a MERGE command will scan all the tuples in target relation and its > children tables. If one tuple in a child table meets the > requirements of INSERT actions, the insertion should be taken on the > child table itself rather than its ancestor.
It seems clear that your work in this area will interfere with the work on partitioning and insert routing. We've seen it time and time again that big projects that aim to deliver towards end of a release cycle interfere with dev of other projects and leave loose ends from unforeseen interactions. There's no need for that. > PS: Since I have taken this project, I will do my best to make it > perfect. I will keep working on MERGE until it is really finished, > even after the gSoC. (unless you guys has other plans). You can make things perfect in more than one phase, as indeed you already are: concurrent locking has already been placed out of scope of your current work. I don't question your good intentions to both complete this work and do it on time. I question the need for us to rely on that. I also question the ability of the community to deliver super-size features in a single release. Breaking things down is always the best way. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
