Amit Kapila <amit.kapila16@gmail.com> writes:
> On Fri, Jul 3, 2020 at 2:06 PM Simon Riggs <simon@2ndquadrant.com> wrote:
>> Seems like a change with low utility.
> Yeah, all or most of the ReorderBuffer APIs seem to take the
> "ReorderBuffer *" parameter, so not sure if removing from some of them
> is useful or not. At least in the current form, they look consistent.
Yeah, I agree with that. This makes things less consistent and it seems
like it's not buying much. Are any of these code paths sufficiently hot
that saving a couple of instructions would matter?
In the long run, it seems like the fact that any of these functions
are not using these parameters is an implementation artifact that
could change at any time. So we might just be putting them back
someday, with nothing except code churn and back-patch hazards to
show for our trouble. Or, if you want to argue that a "ReorderBufferXXX"
function is inherently never going to use the ReorderBuffer, why is it
in that module with that name to begin with?
regards, tom lane
