On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should re-implement this feature by extending the planner to produce a plan tree such as ModifyTable+Limit+Append, maybe with LockRows below the Limit node. Such an approach would prevent duplication of the LIMIT code in ModifyTable, making the ModifyTable code more simple, I think.
You can already change *this patch* to do ModifyTable <- Limit <- LockRows. If we think that's what we want, we should rewrite this patch right now. This isn't a reason not to implement LIMIT without ORDER BY.
Like I said upthread, I think LockRows is a bad idea, but I'll need to run some performance tests first. But whichever method we decide to implement for this patch shouldn't need to be touched when the changes to UPDATE land, so your reasoning is incorrect.
.marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
