(2014/09/10 16:57), Marko Tiikkaja wrote:
> On 2014-09-10 04:25, Etsuro Fujita wrote:
>> (2014/09/09 18:57), Heikki Linnakangas wrote:
>>> What's not clear to me is whether it make sense to do 1) without 2) ? Is
>>> UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
>>> apply this patch now, how much of it needs to be rewritten after 2) ? If
>>> the answers are "yes" and "not much", then we should review this patch
>>> now, and put 2) on the TODO list. Otherwise 2) should do done first.
>>
>> My answers are "yes" but "completely rewritten".
>
> Any particular reason for you to say that? Because an UPDATE might have
> a RETURNING clause, all the updated tuples have to go through the
> ModifyTable node one at a time. I don't see why we couldn't LIMIT there
> after implementing #2.
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.
Thanks,
Best regards,
Etsuro Fujita
