Re: Replace remaining castNode(…, lfirst(…)) and friends calls with l*_node() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Replace remaining castNode(…, lfirst(…)) and friends calls with l*_node()
Date
Msg-id 4c9836e2-ed0b-28a4-1cae-fb448a1af362@enterprisedb.com
Whole thread Raw
In response to Re: Replace remaining castNode(…, lfirst(…)) and friends calls with l*_node()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 08.07.21 20:17, Alvaro Herrera wrote:
>> diff --git a/src/backend/rewrite/rewriteSearchCycle.c b/src/backend/rewrite/rewriteSearchCycle.c
>> index 599fe8e735..c50ebdba24 100644
>> --- a/src/backend/rewrite/rewriteSearchCycle.c
>> +++ b/src/backend/rewrite/rewriteSearchCycle.c
>> @@ -307,8 +307,8 @@ rewriteSearchAndCycle(CommonTableExpr *cte)
>>                         list_nth_oid(cte->ctecolcollations, i),
>>                         0);
>>           tle = makeTargetEntry((Expr *) var, i + 1, strVal(list_nth(cte->ctecolnames, i)), false);
>> -        tle->resorigtbl = castNode(TargetEntry, list_nth(rte1->subquery->targetList, i))->resorigtbl;
>> -        tle->resorigcol = castNode(TargetEntry, list_nth(rte1->subquery->targetList, i))->resorigcol;
>> +        tle->resorigtbl = list_nth_node(TargetEntry, rte1->subquery->targetList, i)->resorigtbl;
>> +        tle->resorigcol = list_nth_node(TargetEntry, rte1->subquery->targetList, i)->resorigcol;
> This seems a bit surprising to me.  I mean, clearly we trust our List
> implementation to be so good that we can just fetch the same node twice,
> one for each member of the same struct, and the compiler will optimize
> everything so that it's a single access to the n'th list entry.  Is this
> true?  I would have expected there to be a single fetch of the struct,
> followed by an access of each of the two struct members.

Lists are arrays now internally, so accessing an element by number is 
pretty cheap.



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: proposal: possibility to read dumped table's name from file
Next
From: Tom Lane
Date:
Subject: Re: Bogus HAVE_DECL_FOO entries in msvc/Solution.pm