Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Date: 2022-07-01 11:10:37
Message-ID: CAEudQArUdR9-yp4rccsoDyVuVR_QhED5XrzHoRwEqdaBS1xCTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qui., 30 de jun. de 2022 às 19:37, Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> escreveu:

> On 19.05.22 18:09, Ranier Vilela wrote:
> > Taking it a step further.
> > Created a new patch into commitfest, targeting 16 version.
> > https://commitfest.postgresql.org/38/3645/
> > <https://commitfest.postgresql.org/38/3645/>
>
> I have committed your 001 patch, which was clearly a (harmless) mistake.
>
Thank you.

>
> I have also committed a patch that gets rid of MemSet() calls where the
> value is a constant not-0, because that just falls back to memset() anyway.
>
> I'm on board with trying to get rid of MemSet(), but first I need to
> analyze all the performance numbers and arguments that were shown in
> this thread.
>
One good argument is that using memset, allows to compiler
analyze and remove completely memset call if he understands
that can do it, which with MemSet is not possible.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2022-07-01 11:18:37 POC: Lock updated tuples in tuple_update() and tuple_delete()
Previous Message Dagfinn Ilmari Mannsåker 2022-07-01 10:47:50 Re: Refactor construct_array() and deconstruct_array() for built-in types