From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Update comments in nodeModifyTable.c |
Date: | 2017-07-31 16:03:17 |
Message-ID: | CA+TgmoYtSPqYn0GrZE2E=Y7RjOowW5vOjHayH_B_25S5AvJz6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 28, 2017 at 8:12 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2017/07/26 22:39, Robert Haas wrote:
>> So the first part of the change weakens the assertion that a 'ctid' or
>> 'wholerow' attribute will always be present by saying that an FDW may
>> instead have other attributes sufficient to identify the row.
>
> That's right.
>
>> But
>> then the additional sentence says that there will be a 'wholerow'
>> attribute after all. So this whole change seems to me to be going
>> around in a circle.
>
> What I mean by the additional one is: if the result table that is a foreign
> table has a row-level UPDATE/DELETE trigger, a 'wholerow' will also be
> present. So, if the result table didn't have the trigger, there wouldn't be
> 'whole-row', so in that case it could be possible that there would be only
> attributes other than 'ctid' and 'wholerow'.
I think maybe something like this would be clearer, then:
/*
* Initialize the junk filter(s) if needed. INSERT queries need a filter
* if there are any junk attrs in the tlist. UPDATE and DELETE always
- * need a filter, since there's always a junk 'ctid' or 'wholerow'
- * attribute present --- no need to look first.
+ * need a filter, since there's always at least one junk attribute present
+ * --- no need to look first. Typically, this will be a 'ctid'
+ * attribute, but in the case of a foreign data wrapper it might be a
+ * 'wholerow' attribute or some other set of junk attributes sufficient to
+ * identify the remote row.
*
* If there are multiple result relations, each one needs its own junk
* filter. Note multiple rels are only possible for UPDATE/DELETE, so we
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Mengxing Liu | 2017-07-31 16:11:59 | [GOSC' 17][Performance report] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions |
Previous Message | Sokolov Yura | 2017-07-31 15:56:20 | Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit) |