| From: | tender wang <tndrwang(at)gmail(dot)com> | 
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> | 
| Subject: | Re: Improve list manipulation in several places | 
| Date: | 2023-04-23 10:13:41 | 
| Message-ID: | CAHewXN=KEdAD8hG8q4o2_e8-HK-dqwxyU-Mx5CjSNcsZ--NVDg@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Richard Guo <guofenglinux(at)gmail(dot)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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2023-04-23 11:58:42 | Re: duplicate function declaration in multirangetypes_selfuncs.c | 
| Previous Message | Richard Guo | 2023-04-23 09:29:59 | Re: Improving worst-case merge join performance with often-null foreign key |