Re: 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Wed, Jul 9, 2014 at 8:42 PM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>
> Hi Amit,
>
>
> On 5/14/14 6:41 AM, Amit Kapila wrote:
>>
>> IIUC, the way new design will work is that for new tuple we will now
>> get tableoid+TID, modified column values as an input (for inheritance
>> tables we will get this for all child tables as well) for ModifyTable
>> and get old tuple (which in current case will be provided by MergeAppend
>> or in general by some scan node) from some node beneath the
>> ModifyTable. It then matches the tableoid from old tuple with
appropriate
>> tableoid incase of child tables and then form the new tuple for that
>> tableoid using old tuple and modified column values.
>
>
> Having now read the discussion upthread a bit more carefully, I think one
of us is confused. AIUI, what was suggested was that the plan nodes below
the ModifyTable node would only give you back the modified columns, the
tableoid and the TID of the tuple, and no "old values" at all.

Plan node below ModifyTable will be a scan node, it will give you old
tuple, whats the use of getting modified columns from it. We need
modified columns for new tuple which can be input for ModifyTuple.

>> In this case can we safely assume that we will always get tableoid from
>> old tuple, ideally it should be there but just not sure
>
>
> It has to be there or otherwise the scheme won't work. Is there a
specific case you're worried about?
>
>
>> and another minor
>> point is won't we get TID from old tuple (tuple we get from node beneath
>> ModifyTable), what's the need to pass for new tuple?
>
>
> I don't understand this part, could you rephrase?

Basically, I wanted to say that apart from modified columns, we just
need to pass table OID. If I am reading correctly, the same is
mentioned by Heikki as well.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com