Re: [PATCH] Redudant initilization

Ranier Vilela <ranier.vf@gmail.com>

From: Ranier Vilela <ranier.vf@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-05T17:44:20Z
Lists: pgsql-hackers
Em sáb., 5 de set. de 2020 às 14:29, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

> Ranier Vilela <ranier.vf@gmail.com> writes:
> > Attached is a patch I made in March/2020, but due to problems,
> > it was sent but did not make the list.
> > Would you mind taking a look?
>
> I applied some of this, but other parts had been overtaken by
> events, and there were other changes that I didn't agree with.
>
I fully agree with your judgment.


> A general comment on the sort of "dead store" that I don't think
> we should remove is where a function is trying to maintain an
> internal invariant, such as "this pointer points past the last
> data written to a buffer" or "these two variables are in sync".
> If the update happens to be the last one in the function, the
> compiler may be able to see that the store is dead ... but IMO
> it should just optimize such a store away and not get in the
> programmer's face about it.  If we manually remove the dead
> store then what we've done is broken the invariant, and we'll
> pay for that in future bugs and maintenance costs.  Somebody
> may someday want to add more code after the step in question,
> and if they fail to undo the manual optimization then they've
> got a bug.  Besides which, it's confusing when a function
> does something the same way N-1 times and then differently the

N'th time.
>
Good point.
The last store is a little strange, but the compiler will certainly
optimize.
Maintenance is expensive, and the current code should be the best example.

regards,
Ranier Vilela

Commits

  1. Yet more elimination of dead stores and useless initializations.

  2. Remove still more useless assignments.

  3. Remove some more useless assignments.