Re: Improve list manipulation in several places

2023-07-03 Thread Richard Guo
On Mon, Jul 3, 2023 at 5:41 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 09.05.23 05:13, Richard Guo wrote: > > Yeah, maybe this is the reason I failed to devise a query that shows any > > performance gain. I tried with a query which makes the 'all_pathkeys' > > in sort_in

Re: Improve list manipulation in several places

2023-07-03 Thread Peter Eisentraut
On 09.05.23 05:13, Richard Guo wrote: On Tue, May 9, 2023 at 1:26 AM Alvaro Herrera > wrote: The problem I see is that each of these new functions has a single caller, and the only one that looks like it could have a performance advantage is list_cop

Re: Improve list manipulation in several places

2023-05-09 Thread Alvaro Herrera
On 2023-May-08, Ranier Vilela wrote: > Em seg., 8 de mai. de 2023 às 14:26, Alvaro Herrera > escreveu: > > > The problem I see is that each of these new functions has a single > > caller, and the only one that looks like it could have a performance > > advantage is list_copy_move_nth_to_head() (

Re: Improve list manipulation in several places

2023-05-08 Thread Richard Guo
On Tue, May 9, 2023 at 1:48 AM Ranier Vilela wrote: > I think you missed list_nth_xid, It makes perfect sense to exist. > It seems that list_nth_xid is more about simplification. So maybe we should put it in 0001? Thanks Richard

Re: Improve list manipulation in several places

2023-05-08 Thread Richard Guo
On Tue, May 9, 2023 at 1:26 AM Alvaro Herrera wrote: > The problem I see is that each of these new functions has a single > caller, and the only one that looks like it could have a performance > advantage is list_copy_move_nth_to_head() (which is the weirdest of the > lot). I'm inclined not to h

Re: Improve list manipulation in several places

2023-05-08 Thread Richard Guo
On Mon, May 8, 2023 at 11:22 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 23.04.23 08:42, Richard Guo wrote: > > Thanks for the suggestion. I've split the patch into two as attached. > > 0001 is just a minor simplification by replacing lfirst(list_head(list)) > > with lini

Re: Improve list manipulation in several places

2023-05-08 Thread Ranier Vilela
Em seg., 8 de mai. de 2023 às 14:26, Alvaro Herrera escreveu: > On 2023-May-08, Peter Eisentraut wrote: > > > On 23.04.23 08:42, Richard Guo wrote: > > > Thanks for the suggestion. I've split the patch into two as attached. > > > 0001 is just a minor simplification by replacing > lfirst(list_hea

Re: Improve list manipulation in several places

2023-05-08 Thread Alvaro Herrera
On 2023-May-08, Peter Eisentraut wrote: > On 23.04.23 08:42, Richard Guo wrote: > > Thanks for the suggestion.  I've split the patch into two as attached. > > 0001 is just a minor simplification by replacing lfirst(list_head(list)) > > with linitial(list).  0002 introduces new functions to reduce

Re: Improve list manipulation in several places

2023-05-08 Thread Peter Eisentraut
On 23.04.23 08:42, Richard Guo wrote: Thanks for the suggestion.  I've split the patch into two as attached. 0001 is just a minor simplification by replacing lfirst(list_head(list)) with linitial(list).  0002 introduces new functions to reduce the movement of list elements in several places so as

Re: Improve list manipulation in several places

2023-04-23 Thread tender wang
Richard Guo 于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

Re: Improve list manipulation in several places

2023-04-22 Thread Richard Guo
On Fri, Apr 21, 2023 at 7:16 PM Ranier Vilela wrote: > +lcons_copy(void *datum, const List *list) > +lappend_copy(const List *list, void *datum) > list param pointer can be const here not? > Correct. Good point. V2 patch does that. Thanks Richard

Re: Improve list manipulation in several places

2023-04-22 Thread Richard Guo
On Sat, Apr 22, 2023 at 12:55 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 21.04.23 09:34, Richard Guo wrote: > > 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 thr

Re: Improve list manipulation in several places

2023-04-21 Thread Peter Eisentraut
On 21.04.23 09:34, Richard Guo wrote: 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 usin

Re: Improve list manipulation in several places

2023-04-21 Thread Ranier Vilela
Em sex, 21 de abr de 2023 9:10 AM, David Rowley escreveu: > On Fri, 21 Apr 2023 at 23:16, Ranier Vilela wrote: > > Perhaps list_delete_nth_cell needs to check NIL too? > > + if (list == NIL) > > + return NIL; > > Which cell would you be deleting from an empty list? > None. But list_delete_nth_ce

Re: Improve list manipulation in several places

2023-04-21 Thread David Rowley
On Fri, 21 Apr 2023 at 23:16, Ranier Vilela wrote: > Perhaps list_delete_nth_cell needs to check NIL too? > + if (list == NIL) > + return NIL; Which cell would you be deleting from an empty list? David

Re: Improve list manipulation in several places

2023-04-21 Thread Ranier Vilela
Em sex., 21 de abr. de 2023 às 04:34, Richard Guo escreveu: > 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

Improve list manipulation in several places

2023-04-21 Thread Richard Guo
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 perfor