(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