(2014/09/10 18:33), Marko Tiikkaja wrote:
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.
I think it might be relatively easy to do that for single-table cases,
but for inheritance cases, inheritance_planner needs work and I'm not
sure how much work it would take ...
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.
Yeah, as you say, we need the performance tests, and I think it would
depend on those results whether LockRows is a bad idea or not.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
