Re: Improve list manipulation in several places - Mailing list pgsql-hackers

From tender wang
Subject Re: Improve list manipulation in several places
Date
Msg-id CAHewXN=KEdAD8hG8q4o2_e8-HK-dqwxyU-Mx5CjSNcsZ--NVDg@mail.gmail.com
Whole thread Raw
In response to Improve list manipulation in several places  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers


Richard Guo <guofenglinux@gmail.com> 于2023年4月21日周五 15:35写道:
There was discussion in [1] about improvements to list manipulation in
several places.  But since the discussion is not related to the topic in
that thread, fork a new thread here and attach a patch to show my
thoughts.

Some are just cosmetic changes by using macros.  The others should have
performance gain from the avoidance of moving list entries.  But I doubt
the performance gain can be noticed or measured, as currently there are
only a few places affected by the change.  I still think the changes are
worthwhile though, because it is very likely that future usage of the
same scenario can benefit from these changes.

    I doubt the performance gain from lappend_copy func.  new_tail_cell in lappend may not enter enlarge_list in most cases, because we
may allocate extra cells in new_list(see the comment in new_list).
 
 

(Copying in David and Ranier.  Ranier provided a patch about the changes
in list.c, but I'm not using that one.)

[1] https://www.postgresql.org/message-id/CAMbWs49aakL%3DPP7NcTajCtDyaVUE-NMVMGpaLEKreYbQknkQWA%40mail.gmail.com

Thanks
Richard

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Improving worst-case merge join performance with often-null foreign key
Next
From: Alexander Korotkov
Date:
Subject: Re: duplicate function declaration in multirangetypes_selfuncs.c