Re: Improve list manipulation in several places

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: Improve list manipulation in several places
Date: 2023-05-08 17:48:28
Message-ID: CAEudQAokF+4g3f1yGF=FMsG+X52uP72po7SjU8YmUOLnf2R+nA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg., 8 de mai. de 2023 às 14:26, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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_head(list))
> > > with linitial(list). 0002 introduces new functions to reduce the
> > > movement of list elements in several places so as to gain performance
> > > improvement and benefit future callers.
> >
> > These look sensible to me. If you could show some numbers that support
> the
> > claim that there is a performance advantage, it would be even more
> > convincing.
>
> 0001 looks fine.
>
> 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 have any of these single-use functions unless
> a performance case can be made for them.
>
I think you missed list_nth_xid, It makes perfect sense to exist.

regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-05-08 18:00:39 Re: Add LZ4 compression in pg_dump
Previous Message Alvaro Herrera 2023-05-08 17:25:58 Re: Improve list manipulation in several places